主题：【原创】好吧，给一个铁道部订票系统的正确答案 -- 布老虎
家园 铁道部的现有系统不受影响 铁道部可以随时决定每天拿多少票在这套系统上发布，其他的窗口人工订票系统照旧。
广大人民群众可以留下email或电话，指定follow哪条线路。铁道部在发布前可以通知大家。
家园 那么用什么异步系统呢？预算？ 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亿不一定够啊，丑话说在前头。
家园 Fund Checking 哈哈，还是猴版交易系统。
衙门办事不力，逼得群众买票要自带系统求DMA了。
家园 估算一下系统的订票响应速度 现在估算一下系统的响应速度。
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分钟。
本帖一共被 1 帖 引用 (帖内工具实现)家园 "事先在铁道部的系统里存钱", 这个存钱的系统大概会死的 节假日前几千万人一起存钱或者查询余额，这个存钱系统说不定死的也很快。可能预付卡更好一点吧。