论坛首页 Java企业应用论坛

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

浏览 9178 次
精华帖 (1) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
作者 正文
   发表时间:2012-01-13   最后修改:2012-01-13

     JE上好多讨论这个主题的帖子,但是水(v)的人远远多于技术讨论的。最近一直在跟同事和网友讨论如何构建一个这样的电子商务网站。
     首先有几个问题先说一下:
     1 今年春节期间铁路客流量据说有2亿多
     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,这样验证是否此人已经订过该票一步搞定,然后异步统计余票。某台机器的票没有了,这台机器就被移除(类似于负载均衡原理,票没了就相当于机器挂了,目前常用的技术是心跳,还是异步统计)

 

 

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

   发表时间:2012-01-13  
2012年全国铁路春运启动 预计发送旅客2.35亿人 http://finance.ifeng.com/roll/20120108/5415214.shtml

31亿是全国公路铁路水运民航的总量,文章重新改过  呵呵
0 请登录后投票
   发表时间:2012-01-13  
samzw 写道
2012年全国铁路春运启动 预计发送旅客2.35亿人 http://finance.ifeng.com/roll/20120108/5415214.shtml

31亿是全国公路铁路水运民航的总量,文章重新改过  呵呵


嗯,我今天看参考消息也看到这个新闻了,我修正一下原文
0 请登录后投票
   发表时间:2012-01-13  
2 目前12306 pv是14亿,而高峰期就在8点到10点,那么也就是有可能在这两个小时里有5亿访问量,而每秒的并发量估计在最高峰时能达到几千万


这个不对,开票时间分时段的。每次高峰也不可能长达2小时,估计10分钟票就没了。以我的经历来看,开票时直接下单,下单成功后,再次查询,无座票都没了。时间不超过2分钟。
0 请登录后投票
   发表时间:2012-01-15  
分析的有道理,赞成
0 请登录后投票
   发表时间:2012-01-15  
这个看着还稍微靠谱点,不用动不动就说让淘宝,腾讯来做,他们来做也一样的问题。


多给点铁道部耐心吧,今年已经不错了。希望明年更好。
0 请登录后投票
   发表时间:2012-01-15  
这个高的并发访问量,对系统,对数据库都是一种超级大的访问能力,很有可能直接将数据库给冲垮;
按照这种规模级别的情况,至少要几百台服务器来应付;
0 请登录后投票
   发表时间:2012-01-16  

先确定瓶颈在哪里再说?

我觉得窗口,电话和12306最终都会到一个集中式系统处理,不然他们如何做到一致?这个系统才是瓶颈所在。等铁道部把这个系统升级再谈架构。

单从12306下手没太大意义,CPU和内存都上去了,总线速度跟不上去,能有性能提升吗。
0 请登录后投票
   发表时间:2012-01-16  
如果系统好了,我可以想象,票被一抢而空。。
0 请登录后投票
   发表时间:2012-01-16  
至少现在系统已经能抗得住了,
不会说URL找不到了。。。。


比刚开始强得多了。。
反正我的票是从上面捡来的。。
0 请登录后投票
论坛首页 Java企业应用版

跳转论坛:
Global site tag (gtag.js) - Google Analytics