系统需求分析
如果设计要应对这种高负载、高访问量的结构，首先考虑这个系统的需求。其实具体过程比较简单：
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万个号，放完了就没有了。用户来晚了，连号都没有，也只能慨叹自己不够及时，这样比系统瘫痪要好得多。
对于这个架构，其设计重点就是把系统整体的资源处于可控的状态。很多类似系统，如：报名，考试，短时间抢购等等实际应用系统，都可以采用类似的方式解决。好的架构，并不是说能解决所有的问题，而是很清楚自己能做什么，不能做什么。
