2009年1月12日星期一

从奥运订票系统瘫痪说起——谈FastCGI 与IT 架构

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

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

关于FastCGI的历史我就不再赘述,好像自1993年便有了。目前最热门的视频网站YouTube体系结构中,就有fast-cgi的模块。它支持很多httpd服务器,在官方网站上列了很多,如apache,aXesW3 ,Microsoft IIS,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 [L]



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

AddHandler fastcgi-script .fcgi

还有一个关键的设置:





Options +ExecCGI





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

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

下面放一段FastCGI程序的C代码,来说明一下:



#include

#include



void main(void){

int count = 0;

while(FCGI_Accept() >= 0) {

printf("Content-type:text/html ");

printf(" ");

printf(" "

"

"FastCGI "

"
"content="text/html; charset=utf-8"> " "Hello world!
");

printf("Request number %d.",count++);

printf(" ”);

}

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万个号,放完了就没有了。用户来晚了,连号都没有,也只能慨叹自己不够及时,这样比系统瘫痪要好得多。

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

没有评论:

发表评论