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

看到这个帖，又到网上搜索了一下一些相关的思考，看到这样一句话：

我觉得这句话说到了根本。现行提前N天售票模式本质上还是为窗口排队的购售票模式定制的。考虑到排队的成本，这种模式对购票者基本上还是公平的。到了电子时代就完全不是这么回事了，因为排队的成本基本为0，另外还有软件外挂加塞，这种提前N天售票的模式的公平意义已经失去了。既然如此，不如改改售票模式，将预售期索性拉得长一点，让购票者抢无可抢。旅客最早可购票日期为旅客行程确定的日子，而非铁路放票的日子，这样购票日期就充分离散化了。为了避免让票贩子钻了空子，可以配套一些措施，譬如：

1.预售票的改签、退票费用固定为20%（或者更高）；

2.因为预售期极长，不可避免有人退票。可以加入电子排队机制供暂时没有买到票的人排队，一旦有人退票，排在前面的人可以自动成交。此机制一则可以防范黄牛先退再买的操作手段，二则可以增强铁路部门的计划性，如果排队的人数较多，可以就此增开临时列车。

3.凭二代证上车。此机制用以防止黄牛购票让乘车人买个短途票实名进站然后凭从黄牛手中购买的长途票坐上真正要的车的座位，焦点访谈有揭露。

“东部某发达省某银行曾经从印度引进过据称是使用Java先进技术开发的银行业务系统，结果每到高峰时段就会出现10分钟以上的延迟和停摆，断断续续解决了两年没有解决，最后忍无可忍换掉了供应商。印度公司从来没有想到，中国东部一个县的交易量就已经能赶上别人一个国家。”

Java先进技术？这尼玛啥JB玩意，我怎么从来没听说过？这典型的JVM excessive GC,那帮堆业务逻辑代码的猪根本没有控制流量的概念。Java根本不能用于大数据处理，你得小心对付。

这尼玛还要两年？Trading floor上down机老子最多只有5分钟。

铁路订票系统的前端问题不大，主要瓶颈发生在数据库一端。原因出自数据库系统的一致性、高竞争性和并发性的三元悖论。三者不能同时保障，必须放弃掉其中之一

如果放弃掉一致性，允许数据出现脏读，那么实时性和并发性都可以得到保证，事实上，MySQL和NoSQL是无法保证一致性的。但由于订票业务是涉及到金钱与资源抢占的业务，因而一致性是不能放弃的，所以采用NoSQL是绝对不行的。如果一致性出了问题，就会出现一票多卖等各种找骂的故障。事实上，能够解决一致性问题的，非企业级数据库不可，使用MySQL和NoSQL的方案绝对会被决策层乱棍打出，谁也不会拿自己的政治生命去验证一个存在已知的严重质量问题的系统的质量，那与赌徒无异。

放弃高竞争性，不同的事务锁定不同的数据行，互不影响，可以解决响应速度问题。但这是不可能的。购票人的行为是不受控的。

所以，解决方案只能是放弃并发性。最为常见的解决方案就是将订票请求单独存放，在最终分票的时候，采取批处理，或者人为串行化队列的方式。

事实上，目前几乎所有需要解决以上三元悖论的系统，都是放弃的并发性。将并发请求通过一级缓冲转化为串行请求。

2000万美元的报价大约不知道软件开发和授权费用是一个怎么样恐怖的数字。2000万美元顶多能解决数据库系统的大型机费用和软件授权费用。能够用于这个级别需求的数据库，授权费用无不是百万美元级别起步的，按照CPU核数算钱。运营方都不是傻子，肯出这样的钱必然是这样能够省更多的钱。

另外Amazon和NYSE事实上竞争程度远不及铁路系统（交易品种更多），并且金融交易本身对于单个人或单只品种而言天然就是串行化的。比NYSE更加竞争性更高的交易市场是类似与CME，CBOT这样的，因为品种有限，且多集中于少数主力合约，远比NYSE这种竞争性要强。对于这种高竞争性的解决一般是通过使用大合约乘数来筛选出少量参与者。所以CME的合约总是挂单量很少。

同样的合约，如果放到DCE或者SHFE就出现问题了，国内合约乘数普遍偏小，因而同一档挂单价格通常会堆积数百挂单，当出现一次1000手的交易指令时，你会感觉到明显的延迟，会堵塞后面的单。并且这种延迟不是可以通过增加并行能力能够解决的。因为金融交易天然是串行化的。

最终交易的有效性也不是实时确定的，事实上金融交易每天要进行结算，这个结算成本很高。就是为了确定实时交易的有效性。因结算发现问题取消掉的实时交易不是没有发生过。