如何设计高并发高流量的12306在线票务系统

bjsemo

已经完了啊~

haizilin

考虑负载均衡？由主服务器分发用户访问请求到其所在区域的子服务器系统，从而减轻主服务器压力。

归隐乡村

技术高的人就是厉害！膜拜下！回复 8# yanyangtian4502


   

pplong

gotolinux 发表于 2012-01-17 19:04
我认为这篇讨论大部分地方可以参考：http://bbs.chinaunix.net/thread-3626937-7-1.html

主要值得提出来 ...

12306这个傻系统设计的时候就没有仔细考虑用户的行为，后来竟然给自己制造拥塞。还有不能实现充值，导致用户订票时间等待时间长，浪费系统资源。

rabbitdjh

    12306这个系统绝非多数人想像的那么简单，其实前端的门户并发量的提高这块，大家提到的意见基本上都很到位。
    这个系统关键的地方是票务交易这块，这块由于订票业务的自身属性，存在着较大的优化局限性。具体的说，订票过程中，不可避免的会产生大量的交易锁。
    举例说明：比如某个具体车次的票，当一个人抢到一张票后，系统为该张票创建一个临时锁，只有当用户支付成功后，交易才会成功；如果交易超过一定时间（比如30分钟）用户还没有进行支付，系统则会回滚该交易。只有这两种情况之一发生后，系统才会解除这个临时锁。
    所以用户大量频繁的订票交易，数据库会不断创建大量的交易锁。这种交易锁会急剧降低数据库的性能，降低系统的并发性。
     

ahnhhh

其实完全可以考资金充值到系统，铁路部门何乐而不为呢，呵呵！就这么简单！

E8software

这个是关系到民生的系统，怎么他们做得那么稀烂。解决方案：1.提高硬件性能，2，估计的大改框架，3，提升运维管理能力，运维管理没有解决掉，其他的都是白搭。

http://www.chinae8.net/cn/cpzx/info_4.aspx?subnavID=125

机器猫II

白痴连样式都没有分离你还指望他搞缓存，读写分离，CDN

wread

集群、redis，这些啥的，都是术的概念，解决不了问题。

必须研究业务，才可对症下药。刚刚看了12360订票的流程。
先看看第一部分，车票查询。

主要查询条件：时间、地点、车票往返。

说白了就是车次，其中涉及到数据一致性，车票剩余数量(可略有误差)。
其实剩余数量稍有偏差是没有关系的，最后得由购买的最后动作确定结果。

1.车次的缓存，形成车次查询结果列表
车次预知，数据量不大，不超过2G， ，99.99999%的查询操作。
查询支持内存查询，多条件,选择mongodb。
如果并发量大，可以考虑mongodb的负载均衡。

2.查询列表的剩余票数处理
异步从关系数据库中获取剩余票数。

3.车次关系数据库的切分
根据车次主键奇偶性[可拓展]，进行水平切分存储，为2的查询性能进行优化。

后续部分再讨论，还没有看完整的流程。


   

海淀辉哥

我觉得忽略本身程序问题的话!!!可以参考下淘宝的方法 前端上一个缓存 前端lvs 中间加nginx和jobbs实现动静分离 结合cdn访问完全没有问题了 瓶颈在于数据库 应该实现大型读写分离 结合之前的一个金融系统mysql读写1:9 我们在去ioe大运动下 肯定得上一套分布式系统可以使用hadoop 或TFS