- 发帖可能变空内容，邪门暂不知所以然
- 『稷下学宫』新认证方式，24年网站打算和努力目标
主题：【原创】好吧，给一个铁道部订票系统的正确答案 -- 布老虎
家园 这个不是这样的 布老虎的想法应该是，想买票，先充钱，买不到票，可以退款。
事先也可以警告买家，下单时看到有票，有可能下单后买不到票，在一两分钟内可以通知买家。
这个跟网上售货的情况有这种区别的原因，货物可以下单后再生产，春运时的火车票可没办法这么做。
一定要对比的话，可以跟一些网上售卖的绝版玩具对比，但那样的网售产品，大多是拍卖的，你觉得春运火车票，可以拍卖吗？
我觉得买家应该可以理解，毕竟排队也不一定能买到票。
家园 技术上支持一下布老虎 这里有位业内人士，给出证据，说明了开源软件技术上的可行性。链接出处
再天马行空一下：
1. 这个实在是最简单便宜的办法：Fuhrer:淘宝已经给出正确答案了，只是很快又被下线了
每卖一张票，给淘宝5毛，1块，估计比自己开发便宜多了，而且快多了。不仅如此，淘宝的可靠性也是经过验证的。
但我猜不出为什么不这么做，估计要业内人士，例如忘情才能给出合理的解释。
2. 如果一定要自己开发，我发现布老虎的方案，技术上基本靠谱。（基于一帆孤的案例是真实的假设，以我的直觉，是真实的）我们可以做个分析：
查到的2012年铁路春运人次为2.2亿。
http://business.sohu.com/20120214/n334635495.shtml假设来回跑，实际坐火车出门人数大约是1.1亿。春运提前一个月售票的话，估算最高峰，可能有5000万人同时在线。（这个数目可能还可以往下调，因为可以用分路段段，分天来发布火车票，这样，不同路段的人，不用同时挤在一起。）
好了，再回头看看一帆孤河友的数据，大概涉及商业机密，他没有说得很细，我也只能拿中间值猜: 500万人同时在线，35台服务器，5个G的带宽，开源数据库Redis。
那么我们在看看布老虎，考虑到5000万人同时在线，10倍的话，至少也是350台服务器，但再考虑其业务逻辑的复杂性（尤其是预付款的支付问题），以及MySQL与Redis的差异，1200台服务器，这个估算确实很合理。
总结：技术上支持布老虎，政治上支持红黑客。
家园 买火车票要身份证吧？这个淘宝不行 家园 量变是要引起质变的 几个M的人是同时提交订单可能和5000万的人同时提交订单还是有区别
那5000万的人同时提交订单，而且订单种类有限数量有限的情况是怎样的？
请参考淘宝双11的时候，淘宝自己也有个别时段不可用的
啥时候来着京东图书打折1天，结果那一天我的订单最后也没有提交出去
量变是要引起质变的，涉及到这么大规模的钱，这么多的人，不要低估了困难
刚才没有看到一帆孤的帖子，他那个系统有明显简化的，铁道部遇到的困难他那里被回避了：
铁道部卖票基本无法拒绝用户，他那里可以将已购买成功的用户过滤掉；
我觉得很惊讶，几M的人在提交订单，前面如果有货就返回信息恭喜人家，然后后台一个中心服务器统一处理，最后是严格不允许超卖的，我是不理解如何实现最后几个同时收到恭喜信息的人不会被误报的，这估计也正是关键的核心机密
家园 你应该还没有理解布老虎的思路 假设峰值5000万人会同时在线，但考虑到有人要搜索路线，查价格，在假设平均地分布在15分钟内拍板决定，估计同一秒钟下单的数目约为5万5。这个应该不算是是很离谱的要求。
下单不是难处，而是每一张票整个Transaction的完成要花时间，如果5万5个Transaction同时进行的话，很可能一下子就把数据库拖垮了。
布老虎的思路，（其实红黑客的思路也一样）就是要排队。
就像售票站点，开100个窗口，这5万5就平均地排在这100个窗口上，一条龙，也就是550个买家。假设每一个Transaction需0.1秒完成，那么最后的一位，大概需要1分钟的时间。
这100个窗口的数字是怎么来的呢，这里是我随意估算的。在实践工作中，就要靠行家的经验了，一般来说，钱越多，硬件越好，设计越好的数据库，这个数字越大，反之则越小。这个数字，其实就是数据库可以并行处理各个Transaction的上限。
这种思路的好处在于，可扩展性。
即使一开始的估算不准，也不要紧，我投多点钱，买多点服务器，开多几个窗口，增加带宽，从而降低排队的时间。
家园 数据库可不能这么用 这100个窗口的数字是怎么来的呢，这里是我随意估算的。在实践工作中，就要靠行家的经验了，一般来说，钱越多，硬件越好，设计越好的数据库，这个数字越大，反之则越小。这个数字，其实就是数据库可以并行处理各个Transaction的上限。这100个窗口直接开在数据库上，可是要当机的。
正确的办法是把一段时间（比如1秒）的所有请求在RAM里列队，归类，去掉重复的，这才insert到数据库服务器里。“5万5个Transaction”在数据库这边，就是TEMPORARY DB（可以在RAM里）里小小的几个表。数据库只需run几个简单的query，然后把结果返回就完了。
这样数据库在每个时段只需做有数的几个index query，一点压力也没有. 而且load是线性增长。如果你窗口直接开数据库上，那么数据就要跑几万个类似的query，每次都要扫描index，读写的压力不说，cpu和内存的压力都很大。
家园 预存的话，估计对于铁总开展金融业务这块是非常有诱惑力的 家园 淘宝已经给出正确答案了，只是很快又被下线了
本帖一共被 1 帖 引用 (帖内工具实现)家园 这里的问题是、如何的产品设计，可以使得在百万并发支付请求 下，有满意的用户体验？ 这不只是技术科技层次的问题。
家园 有的时候好的产品设计能解决技术上无解的问题。 家园 恰好不才做过一个参与人数非常多的抢购系统 今天看到此文，恰好我做过类似的东西，有点小心得。
先挖个坑。
通宝推：李根,家园 好啊，盼望您能谈谈亲身经历 搬小板凳等着看