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

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

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

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

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

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

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

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

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

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