当前位置: 首页 > 网站架构 > 正文

设计12306系统

1 星2 星3 星4 星5 星 (暂无评分)
Loading ... Loading ...
baidu_share

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分钟内成功下订单,则将其踢出订票系统.

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

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

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

本文固定链接: http://www.chepoo.com/12306-bigdata-handle.html | IT技术精华网

设计12306系统:等您坐沙发呢!

发表评论