主题：【原创】好吧，给一个铁道部订票系统的正确答案 -- 布老虎
家园 预付卡不也是得几千万人存钱吗？
家园 如果全都是毫秒级了，干嘛要异步？？？ 按楼主的说法，性能的瓶颈在数据库，那么配置个1000，2000或者5000台sql，就什么都搞定了。还折腾同步异步干什么？
家园 你需要对数据库，Cache之类的延迟有概念 不能闭着眼睛瞎设计。
不过小同学还是善于思考滴，虽然没有实际经验，还是值得表扬。
Memcache一般40ms左右，数据库要高一点，到100-200ms左右。这个仅仅是正常延迟（包括线路延迟，查询延迟）。如果搞一点fancy的query,那就200ms往上了。
所以要在前端做好HTML,从cache里面pull数据（当然也可以从cache里push数据到前端服务器），隔离read request,也就是刷屏请求，不让它进入后端。
只有write request可以进到后端，但是后端有若干业务逻辑，累积延迟就难说了。所以每一步都要用queue来削峰平谷。
你地明唔明啊？
家园 "网络和电话订票每天达200万张"，因此根本用不着异步啊 分离读写没有问题，可以分离读写数据库，读数据库用memcache也好用普通数据库也好，都问题不大
但按你的估计，积累延迟有多少？会不会一次订票的延迟达到不可忍受的地步？
读写分开后，只有订票的业务会访问写入数据库。按我google的结果“8日，铁道部副部长胡亚东介绍，网络和电话订票每天达200万张[B][/B]，从1月1日至8日，12306网站日均点击次数超10亿。”。这样的访问压力级别，即使同步访问也可以轻松应付，压根用不着异步。
家园 问题在于这些订票、点击不是平均分布在24小时的 而是集中在放票的那几个甚至1个小时里面的
家园 简单说吧 小同志，我也想今天打一个冲锋，明天就消灭蒋介石反动派。但是不行啊，革命没有那么简单。我们既要防止右倾投降主义，比如说全国人民永远没法网上订票之类的，也要防止左倾盲动主义，比如像你这样的，随便一个LAMP两天就搭好架子。
总的来说，用async是scalability的要求，是一个good design priciple，是无数先烈用website crash换来的教训。它可以完成和sync call同样的任务，但是容错性和scalability是sync call无法达到的。
In conclusion, anyone who suggests to use blocking calls to scale to the web, should be fired into oblivion.
家园 据说现在很多码农培训学校连《数据结构》都不怎么讲了 家园 What the hell
家园 看了看新浪 册那，这12306居然又宕机了。高，实在是高。
听说国内一帮人还开始搞什么12306开源，估计那帮孙子还在吭哧吭哧地“优化sql”。听着就不靠谱。别SQL了，现在都NoSQL了。
吼一声，转载一定得注明西西河布老虎。
家园 你这个message queue，不怕也是死路一条呀 我有一种感觉，那就是把大象装冰箱里拢共需要几个步骤？
好像一用message queue，就万事大吉了？冰箱门打开，大象塞进去，结束了！
No，No，图森破，奶一捂。
队列这里肯定会成为瓶颈，如果按车次弄他几千个queue，多不多？好像也行，不同的服务器处理不同的车次队列，热门车次多来几个服务器处理
IBM的MQ应对这么大的流量行么，还是自己开发queue管理软件？
家园 所有系统的bottleneck都是数据库 你折腾queue干什么？queue上边又没有收费站，不会造成拥堵。1000个queue输出到1台8G的MySql，一样会堵。如果只有一个queue，下游有300个MySql，一样不会堵。
queue只是一个临时存储的storage而已。
注意原文：前端服务器/cache/数据库/message quque，每样来个300台吧，那就1200台，每台大概$1000，一两百万美刀左右吧。
那么就算300个MySql,每个16G内存吧。假设全国每天开行3000列，预售10天，也就3万个车次，分到300台服务器，每台100个车次，没有任何挑战性。
这也就是我根本不提数据库如何实现的原因，因为数据量实在不值一提，小老鼠一只。
唯一的大象就是全国人民在铁道部的个人账户，我已经详细给出了结论。
家园 论断的大方向是对的 程度有点绝对了.如果处理不好,其它地方也有可能,像什么hard disk access之类.
家园 你具体描述一下除了数据库，什么地方会有硬盘读写？
家园 queue为什么不可能成为瓶颈？ 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就行了。禁止刷屏毫无意义。