从12306谈海量事务高速处理系统

首先有几个问题先说一下：
1 今年春节期间铁路客流量据说有31亿
2 目前12306 pv是14亿，而高峰期就在8点到10点，那么也就是有可能在这两个小时里有5亿访问量，而每秒的并发量估计在最高峰时能达到几千万
3 目前Ngix能处理在线1万，但是实际值一般是8000左右
4 一台IBM大型机要几千万美元，估计加上DB2，交易中间件，得小1亿了
5 腾讯，淘宝等拥有总在线人数4亿规模或者事务处理达到亿级别的规模耗时七八年，总投资估计上百亿 （腾讯资料：1亿在线背后的技术挑战）

6 绝对不能两个人订到同一张票，而看到有票，而点击了下订单又说没票了这种失误是可以容忍的。

 

假设一个车次能坐1000人，有10万个人想订这车次的这个时间的票，那么意味着这10万人要被分别负载到10台机器上，这10台机器要共同去维护这1000张票的余量。简单的分库分表大家都会，但是可能是有成千上万台机器来处理这些用户，而且这些用户还可以订全国的火车票。

 

 

我想到了一些机制来处理，或者说先简化再处理问题：

总原则：不需要所有的人

1 职责分离，将登录，订票（查询，填表，下定单），支付，查订单，查车票等都分成不同的服务，采用不同的集群去处理。

2 登录系统，只要有足够的服务器，大家都可以登录进来，这个十分简单

3 订票，总原则是 让能够进入订票流程的人，快速无障碍的进入系统，设定15分钟为一个阀值，15分钟内成功下订单，则将其踢出订票系统，用户可以拿着订单号通过电话或者登录支付系统进行支付（Apple的网上商店即这样），超过15分钟没搞定的也被踢出，提示操作超时。点击订票之后，进入前置分析机，分析机负责计算背后的机器能负载多少用户下订单。比如目前有1百万人同时点击了订票，而背后只能负载10万人，那么出现一个随机摇号程序，摇出10万人，其他人返回 “系统繁忙，稍后重试”的提示。这10万人被负载在10台机器上，可以进行查询，当点击指定车票（标记为ClickSelectedTicket）后，根据车票被分散到不同的机器上（其实是MapReduce的思想）。比如有1万人被定位到要订票T1，系统扔出900张T1票，留100张容错（随着系统逐步稳定，可减少容错票数），然后大家抢锁，采用乐观离线锁。在最终提交订单时检测

4 可以采用地铁高峰限流的方式（其实Apple购买iphone时也类似），就是增加到达ClickSelectedTicket之后的页面的路径，可以多绕几圈，最终减少并发可能性。

5 采用token机制保障页面必须从第一步点击订票开始进入，不可以绕过中间步骤。以免刷票机器人对系统造成冲击（当然还要做IP限定）

6 将票分到几台服务器上，将购买到该车次该时间车票则将身份证+车次+座位+时间作为key，这样验证是否此人已经订过该票一步搞定，然后异步统计余票。某台机器的票没有了，这台机器就被移除（类似于负载均衡原理，票没了就相当于机器挂了，目前常用的技术是心跳，还是异步统计）

 

 

还需考虑的问题是：一个座位分段卖出问题。各个铁路局分布式提供车票的问题。

http://www.linuxso.com/architecture/17006.html