主题：【原创】好吧，给一个铁道部订票系统的正确答案 -- 布老虎

而是集中在放票的那几个甚至1个小时里面的

7点的时候，可是全国总动员点进去，一趟列车1000人，同时提交申请大概是2万人，这2万个申请同时涌入一个queue，你queue总得有入口排队吧？这个的并发支持情况到底如何我不清楚

同时这么多Queue，他们都要更新memcache，会不会有问题？

还有10亿次点击的问题，你这个queue方案是不身份证判重的，大家照样会刷屏，所以点击数可以认为不变。这个在WEB那里压力仍然巨大，不过似乎12306目前解决得还行

总的来说，我觉得这个方案挺好的，虽然也是异步，但最终得到结果时间理论上也该在1小时之内。

7点的时候，可是全国总动员点进去，一趟列车1000人，同时提交申请大概是2万人，这2万个申请同时涌入一个queue，你queue总得有入口排队吧？这个的并发支持情况到底如何我不清楚

-- 任何queue都可以轻松处理数万个排队，速度极快，这点你不用担心。并发支持是最基本的功能。

同时这么多Queue，他们都要更新memcache，会不会有问题？

-- memcache cluster的连接数可以设置，没有问题，拿不到connection,那就等一会呗。任何cache在并发上出问题，那这个cache实在是最基本的要求都达不到。另外，总共也不会有多少个queue,我看10-20个queue差不多了，具体再说, trivial得很。

还有10亿次点击的问题，你这个queue方案是不身份证判重的，大家照样会刷屏，所以点击数可以认为不变。这个在WEB那里压力仍然巨大，不过似乎12306目前解决得还行

-- 这个架构不存在刷屏查车次问题，因为读请求不需要传到后端，直接查本地hashmap就可以响应，速度极快，用不着刷屏。点击量大可以简单地增加web server就行了。禁止刷屏毫无意义。

这个存钱不就是充值吗？任何时候都可以充值。鼓励人民群众提前一个月存钱不就行了呗。

查询余额这种只读的请求，把订票的查询系统抄一个过来就行了。反正也就是webserver的响应。

现在估算一下系统的响应速度。

1.假设每天发布3000次列车，分布到300个服务器，每个服务器负责10个车次，假设每个车次1000个座位，那就是每台服务器负责10000个座位，也就是10000次写操作。

2.假设所有的写操作同时涌入到新发布的一列车（订票）。

3.假设MySql可以执行1000次写操作/秒，那么10秒以后，应用端收到数据库的“座位已满”信号，剩下在queue里的所有请求以及后续到来的请求都被直接bypass到“错误信息”queue，发短信/email通知，不再连接数据库。

4. 15秒之后（假设总共5秒钟的memcache update 时间），web开始显示座位订满的html，不再有后续的订座请求。

按以上分析，最坏情况20秒到半分钟就可以知道订票情况了。

当然这是最简单的情况。一般应该提供选项比如说卧铺优先，如果没有卧铺才选择硬座之类。这个可以用stored procedure来解决，也可以简单地在应用端解决。

有同学不禁要问，怎么知道座位呢？我觉得最好还是不要同时订购座位和车次，不然的话车次/座位的组合可以搞死很多正常请求。

那就用航空公司的方法吧，开车前5天，上网挑座位就行了。

P.S.

草，忘了还有扣钱这步了，加1分钟吧，那就是最后一哥们大约2分钟可以拿到订票确认，算上email时间。

P.P.S

草，多算了一个零。最后更正：2分钟。

• 回帖要看贴

虽然提前充值是负载均衡的好办法，绝大多数人民群众是不会提前充值的。而且在铁道部存钱会有道德风险，北京的一卡通押金都会有公知质疑，铁道部这种有原罪的单位更会被批臭批倒，会被唾沫淹死的。

铁道部开办储蓄账户要先向人民银行申请吧.预付卡之类的擦边球可能还好一点.

道德风险+公知质疑？Fuck that. 听那帮子公知二货瞎忽悠，啥都别干了。

该干啥干啥，该怎么干就怎么干。

哈哈，还是猴版交易系统。

衙门办事不力，逼得群众买票要自带系统求DMA了。

这些二货把持了舆论，蒙蔽了大多数公众，扰乱了视听，其心可诛。公知们质疑一卡通押金时，我身边的很多人都跟着起哄，在他们看来，只要是政府主导的项目都有原罪。。。

IBM的MQ还是什么其他的？软硬件预算？如果给你2亿的预算，你估计峰值响应可以应付多少查询和购票交易呢？

还有个问题，你说把查询放入hash map，这是在用户端还是在缓存web服务器？如果放入用户端（“读请求不需要传到后端，直接查本地hashmap就可以响应，速度极快”），似乎数据量太大了？

1. 任何一个queue系统都可以处理。注意，这里的数据量很小，几乎所有的订票请求（不是查询请求）都来自每天发布的新车次，那么也就3000车次x1000张票，也就是在最坏情况下，瞬间3百万张票的请求，平均每个server1万个请求，这TMD算啥？排队而已，这又不是实时系统。唯一要注意的是扣钱和占座的次序。我觉得铁道部作为温总理手下的一个衙门，道德的血液应该不少，那么先订票再扣钱，如何？订票的这个queue可能需要persistent。2亿的预算，扣掉30%的所得税，应该有人愿意干。

再说一遍，这个系统的关键是所有的查询请求全部被挡在前端web服务器，进入后端的服务器的请求非常少。因为前端服务器的数量可以几乎无限制地horizontally scale out，所以这个系统可以应付全国人民的要求。

2. Hashmap直接在前端web server上。比如"2月1日起点广州终点上海”索引值为一个html的<div>string“<div>卧铺10张，硬座20张</div>”，直接插入到httpservletresponse里面。我具体不知道铁路内部票控的规矩，大概的排列组合有多少，给你一个判据，几十万左右的用一个hashmap, 几百上千万的组合的话--应该不可能--hash两次，用多个hashmap（自己找consistent hashing去学习一下）。memory实在装不下就放进cache cluster里面，有点延迟无所谓，反正这玩意实时性也不高，差个一两秒的延迟没关系。

P.S.

草，还得修改一次，关于预算...这两个亿里面，不止扣税，还得打足回扣的费用。2亿不一定够啊，丑话说在前头。