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

抓住行家问几个问题：

1. 高峰期有多少人同时在线？

2. 用了几台服务器？

3. 用了什么数据库?

4. 用什么开发UI？

5. 需要多少带宽？

就拿这个做标杆好了，就会觉得火车的订票系统便宜很多。。。

也没有人投诉机票在过年过节时的加价不合理。

真是奇哉怪也！

我觉得是价格管制的问题。。。。

就是铁路交通在我们国家属于自然垄断经营的公共产品，道理上是实行听证制度下的政府指导价格，和你所说的价格管制的概念有一部分是重合的，而民用航空虽然也有指导价格，但是名义上我们还有那么多航空公司竞争，管制上更宽松些，其实另一种跨区域公共运输工具，就是长途客运，它的定价和铁路也很像。

抓住行家问几个问题：

--- 行家谈不上

1. 高峰期有多少人同时在线？

--- 几个M

2. 用了几台服务器？

--- 30台左右

3. 用了什么数据库?

--- Redis

4. 用什么开发UI？

--- HTML

5. 需要多少带宽？

--- 几个G

• 技术上支持一下布老虎

这里有位业内人士，给出证据，说明了开源软件技术上的可行性。链接出处

再天马行空一下：

1. 这个实在是最简单便宜的办法：Fuhrer:淘宝已经给出正确答案了，只是很快又被下线了

每卖一张票，给淘宝5毛，1块，估计比自己开发便宜多了，而且快多了。不仅如此，淘宝的可靠性也是经过验证的。

但我猜不出为什么不这么做，估计要业内人士，例如忘情才能给出合理的解释。

2. 如果一定要自己开发，我发现布老虎的方案，技术上基本靠谱。（基于一帆孤的案例是真实的假设，以我的直觉，是真实的）我们可以做个分析：

查到的2012年铁路春运人次为2.2亿。

假设来回跑，实际坐火车出门人数大约是1.1亿。春运提前一个月售票的话，估算最高峰，可能有5000万人同时在线。（这个数目可能还可以往下调，因为可以用分路段段，分天来发布火车票，这样，不同路段的人，不用同时挤在一起。）

好了，再回头看看一帆孤河友的数据，大概涉及商业机密，他没有说得很细，我也只能拿中间值猜: 500万人同时在线，35台服务器，5个G的带宽，开源数据库Redis。

那么我们在看看布老虎，考虑到5000万人同时在线，10倍的话，至少也是350台服务器，但再考虑其业务逻辑的复杂性（尤其是预付款的支付问题），以及MySQL与Redis的差异，1200台服务器，这个估算确实很合理。

总结：技术上支持布老虎，政治上支持红黑客。

经常有一些专家级的人物，上门推荐自己做什么什么软件都没有问题，看看我们用的软件都能说出一堆问题，这个落后了，那个不合适，应该改造了，只需要n个万元就足够了.....一旦你信任了他，就陷入无群无尽的麻烦，开始他还很积极修改，过了一个月，找都找不到人。

我们需要的不是什么先进的东西，是好用能用的东西。

几个M的人是同时提交订单可能和5000万的人同时提交订单还是有区别

那5000万的人同时提交订单，而且订单种类有限数量有限的情况是怎样的？

请参考淘宝双11的时候，淘宝自己也有个别时段不可用的

啥时候来着京东图书打折1天，结果那一天我的订单最后也没有提交出去

量变是要引起质变的，涉及到这么大规模的钱，这么多的人，不要低估了困难

刚才没有看到一帆孤的帖子，他那个系统有明显简化的，铁道部遇到的困难他那里被回避了：

铁道部卖票基本无法拒绝用户，他那里可以将已购买成功的用户过滤掉；

我觉得很惊讶，几M的人在提交订单，前面如果有货就返回信息恭喜人家，然后后台一个中心服务器统一处理，最后是严格不允许超卖的，我是不理解如何实现最后几个同时收到恭喜信息的人不会被误报的，这估计也正是关键的核心机密

红黑客网友其实就是典型的自以为懂开发或者工程，其实就一别人产品的一用户水平。我一看到哪个什么三元悖论就直接呕吐了。。。就铁道部这个东西，选了技术方案架构搞不定了就来个悖论，这不是废话么：条件都给定了，当然就悖论了。

我也给一些低水平的货上上计算机体系架构和组成原理的课吧。

高访问量这玩意，应该找的东西不叫悖论，叫瓶颈，啥瓶颈？数据库！为啥？因为是硬盘！咋解决？在内存里搞！咋搞？布老虎给了答案。

红黑客一类的网友开口闭口懂业务，其实他们还真不懂业务。从宏观上看，恰恰就是因为这种"懂业务"的人太多了，才轮得到哪些通用企业信息系统(erp, crm, finace ...)卖大价钱. 他们其实只知道把自己会搞的东西叫业务，对业务本身，对技术就却是一知半解，理解不深刻。否则早就自己开发各种 通用的 和 专用的 信息系统赚大钱了。

红黑客网友，我上面这一段话隐含一个真正的悖论，请认真领会。

假设峰值5000万人会同时在线，但考虑到有人要搜索路线，查价格，在假设平均地分布在15分钟内拍板决定，估计同一秒钟下单的数目约为5万5。这个应该不算是是很离谱的要求。

下单不是难处，而是每一张票整个Transaction的完成要花时间，如果5万5个Transaction同时进行的话，很可能一下子就把数据库拖垮了。

布老虎的思路，（其实红黑客的思路也一样）就是要排队。

就像售票站点，开100个窗口，这5万5就平均地排在这100个窗口上，一条龙，也就是550个买家。假设每一个Transaction需0.1秒完成，那么最后的一位，大概需要1分钟的时间。

这100个窗口的数字是怎么来的呢，这里是我随意估算的。在实践工作中，就要靠行家的经验了，一般来说，钱越多，硬件越好，设计越好的数据库，这个数字越大，反之则越小。这个数字，其实就是数据库可以并行处理各个Transaction的上限。

这种思路的好处在于，可扩展性。

即使一开始的估算不准，也不要紧，我投多点钱，买多点服务器，开多几个窗口，增加带宽，从而降低排队的时间。