2008年，对于首都人民来说，没有什么比奥运会更大的事情了。如何买到一张称心如意的比赛门票，也成了很多人的一个梦想。然而，在奥运官网抢票购买的时候，这个梦想却轻易地被网上购票系统的当机击成碎片，很多充满热情的老百姓们也因此郁闷无比。由于搜狐承担了奥运的官网，我又在那里工作过相当长一段时间，很多兄弟抢票失败，于是便认定是搜狐开发的系统太烂，而找我抱怨。其实当时我也很是郁闷：首先这个系统并非搜狐开发；其次我也不在搜狐了。虽然如此，和我同行的一些朋友，又开始问我如何解决类似问题。我也反反复复讲了很多次，为了让广大读者能够深入了解背后的原因和机制，写出来，大家一起讨论可能效果会更好。当然，这并不是我说的架构就一定能解决问题，仅仅是抛砖引玉而已。
在说架构之前，我先说一个老的技术，FastCGI。因为这个技术在后面的结构阐述中将起到非常重要的用处，原以为应该会有不少人会知道，但后来发现好像并非如此。
关于FastCGI的历史我就不再赘述，好像自1993年便有了。目前最热门的视频网站YouTube体系结构中，就有fast-cgi的模块。它支持很多httpd服务器，在官方网站上列了很多，如apache，aXesW3 ，MicrosoftIIS，Zeus，近几年才出的lighttpd没写，其实这个新的httpd也支持，但我个人觉得，支持最好的，可能还是Apache。
先讲讲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、Dynamic mode：动态模式，可以使用各种各样的fastcgi，加入到httpd.conf中间去，比如：
AddHandler fastcgi-script .fcgi
还有一个关键的设置：
<Directory /path/to/MyApp>
Options ExecCGI
</Directory>
这个配置建议放在cgi-bin 这种类似的目录里面。
请注意第二种，服务器起几个进程，是由-processes 1 这个参数来控制的，所以起多少你可以自己来定，我们在下面的一个关键模块中将使用这个模式。
下面放一段FastCGI程序的C代码，来说明一下：
#include <fcgi_stdio.h>
#include <string.h>
void main(void){
int count = 0;
while(FCGI_Accept() >= 0) {
printf("Content-type:text/html ");
printf(" ");
printf("<HTML> "
"<HEAD>
"<TITLE>FastCGI</TITLE> "
"<META http-equiv="Content-Type" "
"content="text/html; charset=utf-8"> <body> " "Hello world!<br> ");
printf("Request number %d.",count );
printf("</body></html> ”);
}
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万个号，放完了就没有了。用户来晚了，连号都没有，也只能慨叹自己不够及时，这样比系统瘫痪要好得多。
对于这个架构，其设计重点就是把系统整体的资源处于可控的状态。很多类似系统，如：报名，考试，短时间抢购等等实际应用系统，都可以采用类似的方式解决。好的架构，并不是说能解决所有的问题，而是很清楚自己能做什么，不能做什么。
PHP的FastCGI
PHP的FastCGI使你的所有php应用软件通过mod_fastci运行，而不是mod_phpsusexec。FastCGI应用速度很快 是因为他们持久稳定。不必对每一个请求都启动和初始化。这使得应用程序的开发成为可能，否则在CGI范例是不切实际的（例如一个大型的脚本，或者一个需要 连接单个或多个数据库的应用）。
1. FastCGI 像是一个常驻 (long-live) 型的 CGI，它可以一直执行着，只要激活后，不会每次都要花费时间去 fork 一次 (这是 CGI 最为人诟病的 fork-and-execute 模式)。
2. FastCGI 可在任何平台上使用，Netscape Enterprise 及 IIS 都有 FastCGI 的模块可供使用，阿帕契 (Apache，以及利用 Apache 衍生出做的服务器) 上也有 mod_fastcgi 可用。
3. FastCGI 支持 C/C 、Java、PHP、Python、Ruby、Perl，Tcl 等程序语言。
4. FastCGI 的应用程序亦兼容于 CGI。即 FastCGI 的应用程序也可以当成 CGI 来执行。
5. 现有的 CGI 程序要改写成 FastCGI 非常简单，最少可能只需要多加入三行程序代码。
6. FastCGI 的侦错方式与 CGI 大同小异，只要带入程序所需的环境变量及参数，即可在命令列模式执行或侦错。
7. FastCGI 应用程序的写作方式与 CGI 类似，除了几项原则要特别注意外，FastCGI 的写作方式跟 CGI 几乎一样，与学习 Web Server API 比较起来， FastCGI 简单多了。
8. FastCGI 支授分布式运算 (distributed computing)，即 FastCGI 程序可以在网站服务器以外的主机上执行并且接受来自其它网站服务器来的请求。 好处
1. PHP脚本运行速度更快(3到30倍)。PHP解释程序被载入内存而不用每次需要时从存储器读取，极大的提升了依靠脚本运行的站点的性能。
2. 需要使用更少的系统资源。由于服务器不用每次需要时都载入PHP解释程序，你可以将站点的传输速度提升很高而不必增加cpu负担。因为dll文件不再每次都载入了，那么数据库的持久连接也将可以起到它设计初的效果。
3. 不需要对现有的代码作任何改变。
潜在问题
1. 对所有的子目录（/home/USERNAME/public_html/php.ini）你只有一个可用的php.ini文件。这是优化网站代码所必需的。如果你需要多个php.ini文件以适应不同的脚本需要，你可以在任何子目录禁用PHP的快速CGI，而其余的地方则继续有效。
2. 你对PHP环境做的任何升级（如php.ini文件的改变）都有几分钟的延迟。这是因为为了更快的速度 你的php.ini文件已经被载入内存，而不是每次需要时再从存储器重新读取。
本文由来源 21aspnet，由 javajgs_com 整理编辑，其版权均为 21aspnet 所有，文章内容系作者个人观点，不代表 Java架构师必看 对观点赞同或支持。如需转载，请注明文章来源。
