hi 各位， 上两周一直都在做泰捷商城这个项目。这个项目的目的就是卖泰捷出品的WEBOX。这是我第一次做有关电子商务的网站。各种头绪。其实原始需求很简单，只卖一件商品，每星期只卖一次。 但是online to offline是从来不是一件简单的事情。因为这一次你所做的事情不仅仅是在线上，而是很多事情要发生在线下的真实世界里。这是一件非常的消耗精力的事情。但人又是生活在现实生活中。比如订单的流转。因为这一次我们不仅仅是做一个订单，而是要把订单真正的转换成工厂生产出来的货物，而且要通过物流公司真正的把货物运送到顾客的手中。再比如说钱的流转，要做到即时又安全。

6月24日，商城的第一次上线就遇到了很严重的问题。事情是这样。由于程序错误，在中午12点开售的时候，倒计时完成，但是购买入口的按钮一直都没有出现。于是当时所有人开始刷新我们的官网。而我们的官网的首页有非常多的图片，而且有的图片甚至没有进行压缩。比如一张只有几十个像素乘以几十个像素的图片竟然有1.2MB的大小。因此产生了大量的并发连接和502错误。浏览器上我们的官网根本打不开或者是打开速度非常慢，而这又会导致更多的页面刷新。简而言之，我们的官网瘫痪而用户请求像滚雪球一样越来越大，也就是服务器雪崩。

不过不幸中的万幸是虽然我们的官网服务器崩溃了，但是我们商城的服务没有受到太多的影响。因为它们在物理上是隔离的。而且因为官网的崩溃，避免了用户在同一时间蜂拥到商城服务器。因为崩溃的时候，我们的运营人员在论坛和QQ群等地方发布我们商城服务器真正的购买入口URL，但这种场景，用户是没有办法在同一时间蜂拥到商城的。我们卖完1000台的时候已经是中午1点半了，比预计的时间慢了太多。最初我们预计在10分钟之内就会卖光。

第一次泰捷售卖就这么草草收场了。虽然不是特别成功，但是由于这是泰捷成立以来卖出的第一批WEBOX，第二天我们还是在公司开了几瓶香槟。我想这是我最尴尬的一次庆功了。我人生中开过三次香槟。第一次是微信注册用户过2亿（当时是作为编外人员参加的，只吃饭不能抽奖）。第二次是微信海外注册用户超过1亿。这是第三次了。不过这次确实是非常的尴尬，我都没好意思喝香槟。

总结一下这一次的抢购。失败的地方：

1 购买入口放在的页面太多图片，下载速度过慢。

2 程序错误导致购买入口无法展示。

3 大量的用户刷新请求导致雪崩。

成功的地方：

1 官网服务器与商城服务器分离，一边崩溃的时候，另外一边没有受到影响。

总结了第一次的得失，我们改进的地方第一就是把我们官网的展示购买入口的页面做的非常简单，基本上没有图片。第二在倒计时完成的时候不发起任何的动态请求。第三把官网全部改成用CDN的形式访问。其实基本上只需要把图片全部放在CDN上就可以了。不过全部放在CDN上更加保险一点，不过费用也更高。

再做一些更深层次的思考，如何做一个高并发的网站？ 如何预估一个网站的设计容量是否足够？

首先要考虑系统可能可能出现瓶颈： 带宽，并发连接数, CPU和IO、内存。如何评估带宽和并发连接数不会超限？ 首先需要预估出你的PV。特别是抢购类的网站，用户过来冲垮你可能就是开始的那一两秒钟的事情。所以你必须要搞清楚在那一两秒中的时间有多少人一起刷你的网页。

然后我们发现， 带宽、并发连接数和内存是不太好通过压力测试去模拟真实情况的。因为利用压力测试比较容易模拟的是大量的重复transaction， 而不好模拟的是大量的并发transaction。比如你可以模拟100、200、400、1000个客户端去重复发送请求产生压力，但你很难去模拟1W,2W，10W个真实的客户端请求。不过，可以通过你的PV来计算出真实的带宽、并发连接数和内存。

计算方法如下：

带宽　＝　PV * 平均每页面的资源数 *平均每个资源的大小

并发连接数　＝　带宽 / 平均下载速度 = PV * 平均每页面的资源数 * 平均每个资源的平均下载时间

举例来说明：

PV是100/s， 每个页面要下载30个资源， 平均每个资源大小为100KB。

带宽 =  100/s * 30 * 100 KB = 300MB/s 

平均每个资源下载速度为 100KB/s

并发连接数 = 300MB/s / 100KB/s = 3000

内存需要根据并发连接数来估算，

例如当你在100并发连接时 占用1MB内存， 那么3000并发连接时， 内存估计消耗为30MB。 不尽准确，但可以作为参考。 

CPU基本和平均每秒请求量相关。

IO和平均每秒请求量先关，和CACHE大小和命中率相关。

在优化静态网站的时候，可以根据上面的公式来做优化。比如怎么降低带宽？ 回到公式， 带宽　＝　PV * 平均每页面的资源数 *平均每个资源的大小。 可以有很多方法， 比如我们可以通过降低平均每个页面的资源数量来解决， 减少一些图片或者是其他资源。也可以降低每个资源的平均大小，多使用304或者是压缩一下图片和JS等。 还有就是降低PV， 比如用一些AJAX的请求代替页面的全部刷新等。

另外一个问题就是动态请求的容量如何预估的问题了。首先要压力测试去测试出所有动态请求的最大QPS。 找出QPS最低的那个请求即为系统的短板。系统的最短板的QPS即为动态请求的最大容量了。动态请求的最大容量不能满足系统的请求怎么办？ 纵向扩容， 平行扩容， 优化代码， 实在没有办法，还可以做过载保护，实现服务柔性可用。不过这个议题的内容太大，不做过多讨论了。

经过总结， 我们在7月1日的第二次抢购就比第一次进步了许多。人生中总有很多第一次的事情会发生， 第一次可能成功也可能会失败。我想失败不可怕，关键是吸取教训做好下一次。