[纯技术讨论]从12306谈海量事务高速处理系统

JE上好多讨论这个主题的帖子,但是水(v)的人远远多于技术讨论的。最近一直在跟同事和网友讨论如何构建一个这样的电子商务网站。
首先有几个问题先说一下:
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

posted @ 2012-05-29 17:47  岁月无情--老胡  阅读(514)  评论(0编辑  收藏  举报