2008年，对于首都人民来说，没有什么比奥运会更大的事情了。如何买到一张称心如意的比赛门票，也成了很多人的一个梦想。然而，在奥运官网抢票购买的时候，这个梦想却轻易地被网上购票系统的瘫痪击成碎片，很多充满热情的老百姓们也因此郁闷无比。由于搜狐承担了奥运的官网，我又在那里工作过相当长一段时间，很多兄弟抢票失败，于是便认定是搜狐开发的系统太烂，而找我抱怨。其实当时我也很是郁闷：首先这个系统并非搜狐开发;其次我也不在搜狐了。虽然如此，和我同行的一些朋友，又开始问我如何解决类似问题。我也反反复复讲了很多次，为了让广大读者能够深入了解背后的原因和机制，写出来，大家一起讨论可能效果会更好。当然，这并不是我说的架构就一定能解决问题，仅仅是抛砖引玉而已。

　　在说架构之前，我先说一个老的技术，FastCGI。因为这个技术在后面的结构阐述中将起到非常重要的用处，原以为应该会有不少人会知道，但后来发现好像并非如此。

　　关于FastCGI的历史我就不再赘述，好像自1993年便有了。目前最热门的视频网站YouTube体系结构中，就有fast-cgi的模块。它支持很多httpd服务器，在官方网站上列了很多，如apache，aXesW3 ，Microsoft IIS，Zeus，近几年才出的lighttpd没写，其实这个新的httpd也支持，但我个人觉得，支持最好的，可能还是Apache。

　　FastCGI的原理
先讲讲FastCGI的原理，它和现在常用的运行请求不同，维基百科上有一个术语形容它，这里借用一下：

　　 短生存期应用程序

　　 长生存期应用程序

　　CGI技术的机制是：每次当客户请求一个CGI的时候，Web服务器就请求操作系统生成一个新的CGI进程;当CGI满足要求后，服务器就杀死这个进程。并且服务器对客户端的每个请求都要重复这样的过程。

　　而FastCGI技术的机制为：FastCGI程序一旦产生后，它可以持续工作，一直保持满足客户的请求直到自己被明确终止。如果你希望通过协同处理来提高程序的性能，你可以请求Web服务器运行多个FastCGI 应用程序。

　　由此CGI就是所谓的短生存期应用程序，FastCGI就是所谓的长生存期应用程序。

　　由于FastCGI程序并不需要不断产生新进程，可以大大降低服务器的压力。并且产生较高的应用效率。如今，流行的Java语言Servlet技术，在设计上就是参考FastCGI技术。

　　FastCGI 配置运行一般来说分三种，这三种都需要Apache的mod_fastcgi 进行处理。

　　1、Standalone FastCGI Server， 应该是独立的服务器。
首先是需要把fastcgi作为单独的守护进程：

　　$ script/myapp_fastcgi.pl -l /tmp/myapp.socket -n 5

　　以下是这个fastcgi的守护进程的参数：

　　-d -daemon #作为守护进程

　　-p -pidfile #管理进程的PID写入到到文件的名称

　　-l -listen #SOCKET的路径，机器名:端口, 或者端口

　　-n -nproc #起始接受请求的进程数

　　然后把下面的代码加入Apache的HTTPD.CONF：

　　FastCgiExternalServer /tmp/myapp -socket /tmp/myapp.socket

　　Alias /myapp/ /tmp/myapp/

　　# Or， 可以使用root的身份运行

　　Alias / /tmp/myapp/

　　# Optionally，(使用rewrite模块)

　　RewriteRule ^/myapp$ myapp/ [R]

　　然后重启Apache就OK了

　　2、Static mode：静态模式， 一般是用于单一确定的模式，就是在Apache 的httpd.conf 中间加上：

　　FastCgiServer /usr/local/apache/count/count.fcg -processes 1

　　Alias /c /usr/local/apache/count/count.fcg

　　此处建议再使用REWRITE的方式 重写整个的URL匹配， 使之看起来像一个静态页面。

　　RewriteRule read-(.+)-(.+)-(.+).html$ /c?id=$1&sid=$2&port=$3 [L]

　　3、Dynamic mode：动态模式，可以使用各种各样的fastcgi，加入到httpd.conf中间去，比如：

　　AddHandler fastcgi-script .fcgi

　　还有一个关键的设置：

　　

　　Options +ExecCGI

　　

　　这个配置建议放在cgi-bin 这种类似的目录里面。

　　请注意第二种，服务器起几个进程，是由-processes 1 这个参数来控制的，所以起多少你可以自己来定，我们在下面的一个关键模块中将使用这个模式。

　　下面放一段FastCGI程序的C代码，来说明一下：

void main(void){
　　int count = 0;
　　while(FCGI_Accept() >= 0) {
　　printf("Content-type:text/html ");
　　printf("Hello world!");
　　printf("Request number %d.",count++);
　　}
　　exit(0);
}

　　这是一个很简单的例子，就是简单的计数， 大家可以注意这一句：while(FCGI_Accept() >= 0)

　　这就是它和普通的短周期程序最大的不同，一般CGI都是运行完就退出了，这个FastCGI，在处理完一个请求完毕后，会回到初始状态等待下一次请求; 如果这个程序被设置成为只能启动一个，那么无论是否访问这个页面，都是在前一个的基础上加一，而不会又产生新的进程;从而后来者是从零开始。当然，很多人也都注意到，此处就是一个死循环在不断处理;如果程序比较复杂，存在内存泄露的问题，此处产生的问题也要比普通CGI要严重得多，所以使用它对于程序员的要求也更高。

　　上述方案应该是所有的Web应用解决方案中，执行效率和速度最高的。官方数据是说比一般的高15倍左右，在我的机器上测试，基本上每秒能够处理大概2400次请求。

　　再回到我们说的正题：奥运订票系统的瘫痪，关于访问量，当时的说法是800万/小时，那么平均到每秒就是超过2200次。这对于订票系统来说，确实是一个非常大的考验。毕竟这种状况下，数据库是肯定承担不住这个量级的访问了。如何进行架构设计，是我们都需要面对的问题。
系统需求分析　
如果设计要应对这种高负载、高访问量的结构，首先考虑这个系统的需求。其实具体过程比较简单：

　　1.用户认证

　　2.查看所有可以订票的项目和票的数量

　　3.选择项目，放入购物车

　　4.确认并提交订单

　　5.订单成功扣款

　　过程虽然简单，但其实里面的东西也不少。

　　由于用户的数据量很大，注册用户数百万以上;而且这种系统，登录用户在操作时应该不存在普通应用的2/8原则。在抢票的当天，绝大部分注册用户都会登录，而且时间会非常集中，所以并发会非常大。你如果预算充足，放一万台服务器来做这个事情，做一个分布算法，然后每台服务不超过十万个用户，这样你就能充分保证你的用户感受和体验。可我想实际上没有哪个公司和系统会这么做，即使是财大气粗的奥组委。

　　这个时候，很多人可能会想：上面提到的FastCGI这种高效率的程序就是针对类似状况的解决方案，其实这是很常见的错误。我想这个订票之所以会瘫痪，就是由于部分设计过于高效，而部分不可能那么高效的缘故。比如登录这个模块的效率估计就非常高，因为登录只是在数据库对比一下用户名和密码，而且数据更新也不频繁，完全可以用分布式数据库来解决。但用户登录后，所有的压力会全部压在后面的功能上，从而造成系统的瘫痪。这个时候，由于人太多，你无论怎么高效，在执行到后面复杂的购买功能时，都会出现瓶颈。而如果真的放一万台服务，你的数据如何分布同步，然后真的做到先来先得，会很难，如果设计的不好，和抽签也就没什么两样了。

　　所以这个系统设计的策略应该是：如何做到在保证用户感受的情况下，合理控制进入系统的人数，这样你后面的设计和开发的压力会小的多，而且成本的控制非常清楚。

　　那么剩下的做法就很清晰了：系统的重点是用户登录，而不是一般理解的后面购票提交的系统功能。如何控制进入的人数，我觉得不妨参考银行的叫号方式来设计：系统先给用户发号，然后当了解到有资源空出来时，再让用户登录。

　　这个结构的重点就在呼号中心和序列号的分配上面。

　　1. 序列号分配中心，技术重点在于高效和唯一性。也就是说当用户访问数达到海量之后，你需要非常迅速地分配唯一的序列号给登录的用户。这种状况下，其他很多技术无法承担这种需求。开始提到的 FastCGI，就是这个模式下的唯一选择。我们在开始安装的时候，就可以使用这种只起单个进程的模式，所以分配用户的序列号只会是唯一的。由于 FastCGI的高效率，从而保证登录的用户可以迅速分配到一个号，然后离开。当然如果你还不放心的话，还可以在前面再加一个负载均衡的设备，完成对几个不同服务器负载分配，然后每个机器加不同的步长，并且起始数字不一样。比如：如果你有2台机器做发号工作，第一台起始数字为1，第二台为2，步长为二，就是每次累加2，这样用户在不同的机器上也会得到唯一的号，而效率就能提高两倍。

　　至于记录用户序列号的方式，可以用cookie记录在客户端，然后进行加密。用户记录后，进入呼号中心，比对手里的号和前面排队的人数，然后提示用户前面排队人数。比方说，你上来就是排号在3千万以后了，前面有2千多万人，我想如果这个人头脑正常的话，就不会说这个系统太烂，只能说自己起晚了，然后感叹中国人实在是太多，就不会再上去反复不停地登录。

　　2. 呼号中心，这里大概是最麻烦，也是最关键的地方。由于订票系统是B/S结构，服务器端有动作的时候，如何通知客户端是一个要点。也就是说，当有人订票完毕，从系统中退出，此时，中控中心知道后，会通知呼号中心呼叫下一个。呼号中心如何找到应呼叫的号码，有两种解决方法，具体实现都不妨通过AJAX的局部刷新达成。

　　第一种，和叫号系统的号进行比对，如果发现匹配成功，就通知客户端进入系统。

　　第二种，判断这个用户前面的排队数量，如果发现为零，就触发进入这个系统的动作。

　　还要注意一点，就是刷新时间长短和叫号的失效问题。时间太短，服务器压力会很大;时间太长又会容易造成这个用户感觉没有变化，从而感受很差。所以这个时间的设置，个人觉得在5-15秒之间调整会比较合适。然后压力需要分摊，也就是叫号服务器需要设置多个。这样的话，用户刷新会命中不同的服务器，此时需要对数据的同步进行特殊处理，其架构如下：

　　这个消息接受模块可以有两种模式取信息：短连接，每隔一段时间来传递信息;长连接，就是在消息接受和中控服务器中建立一个长效的消息通知机制。由于对于信息及时性的要求比较高，所以采用长连接比较合适。

　　消息接受模块和中控服务器之间需要进行序列号的交换。由于你不知道捏着这个号的用户命中哪台服务器，所以失效机制需要在几个服务器上同时进行。也就是说，当一个用户退出，中控服务器知道后，开始确认最后一个登录号，然后发给所有前端，前端要能保证通知到用户，然后向用户发出通知，说明如果在给定次数内用户还不进行登录或者认证，就提示后端此号失效，系统再分配下一个号给前端进行通知，

　　如果要设计得更加精巧，还可以建立前端服务器之间的消息通知机制。就是当一台服务器发现这个号在自己上面，就通知几个前端，不再对这个号进行判断，尽量节约资源。

　　3. 中控服务器。我在开发社区和直播间的时候，都用到了这种方式，此处也用到了。不过在这个系统中，中控服务器不必使用单独的物理服务器，这里可以只是一个模块，它的主要用途是通知这些叫号服务器。由于数据很简单，所以中控的分发比较容易，不用设计特别复杂的协议。

　　4. 认证中心：唯一需要改动的，就是判断用户的序列号是否可用并且是真正的号码。

　　5. 购票中心：此处有很多种分布的方法，有很多可以借鉴的结构，这里就不赘述了。在这个架构中，购票唯一需要确认的就是可以同时承担多少人同时在线购买

　　前三个部分是这个架构的核心部分，由于进入的人数可以控制，后面的系统就还可以使用老的订票系统，只用确认同时放进来多少人就可以，也就是窗口没变，只是大家不再一拥而上，都是文明人，请排队拿号。

　　当然后面的架构还可以重新进行优化和设计，从而尽可能提高放进来人的数量，在进行设计购票功能时还可以借鉴这方面的模式。比如：篮球是爱好观众比较多的运动，大家都想到现场看看科比同学的扣篮，进来人后，可能大家都会一拥而上先抢这个，从而造成局部的数据瘫痪，影响整个系统。此时也可以在里面暗含这个模块。买票的人少，拿号看不出来，拿了就能进去;一旦人数到了极限，对不起，也请排队。

　　限制人员进入后，未进入的人和购买的人不在同一个系统中，从而不会妨碍进入的人，买的人也会很快解决，他们可以迅速完成订单。提交后，系统发现这个人无法再订其他球票的时候，就可以认为再放一个人进来，或者干脆做绝一点，马上将其踢出去，以节约资源。

　　而且，由于你可以控制进入的用户数量，从而系统其他部分的设计简单多了。多大的钱办多少事，如果领导想快一点了事，预算充足，那么放入的人就多;如果心里面没底，那么可以先放很少人进来，或者说大概估计一下，只放多少号，如就卖10万张票，那么只放50万个号，放完了就没有了。用户来晚了，连号都没有，也只能慨叹自己不够及时，这样比系统瘫痪要好得多。

　　对于这个架构，其设计重点就是把系统整体的资源处于可控的状态。很多类似系统，如：报名，考试，短时间抢购等等实际应用系统，都可以采用类似的方式解决。好的架构，并不是说能解决所有的问题，而是很清楚自己能做什么，不能做什么。