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

有关部门可以参考这个架构，向各电商招标；然后向各安全公司招标开发安全和压力测试服务。进贡最多的头2-3名中标，按省分，银子大把进账。

当然楼主这种人才，没必要浪费。可以把架构作为**资格认证考试题，让考生挑错。收认证费、培训费，楼主如果能拉来学生，可以当培训班老师，告诉他学生中有妹纸，不给工资只给期权和提成因为是创业，做好了可以转体制内。大把楼主这样的抢着来 :)

del

随着电子技术的发展和电子货币的发展，很可能在未来身份证肯能成为个人集身份证明，电子商务，购票，社会经济活动等一切人类活动的通行证

楼主忽略了一个很大的问题，售票这个事情你完全不可预测用户的需求，所以跟数据库offline可能不行，你想要的车票库存信息可能需要消耗大量数据库资源。为什么有这个问题呢，因为列车售票是一个弹性资源，比如从广州到北京1000个座位，可能1000张广州到北京，也有可能500个广州到北京，剩下的500个座位就被各种短途需求拆分了，定期去库存数据这个想法恐怕就很难实现了，因为你不知道用户要买一张坐几站的票。

你看看下面的“铁道部现有系统不受影响的帖子”。

票控是铁道部的现有legacy系统。

正常年份下 全年的需求曲线都是可以预期的 甚至变化趋势也是可以大致估计的

当然 撞到08年冰雨那样的天气例外 不过那时候也就不是铁道部一家的事情了

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

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

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

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

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

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

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

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

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

就是奥巴马care的网站，花了近亿美元，流量顶不住了。

相信只读操作大家都会用cache解决，但有复杂逻辑的减库操作才是性能瓶颈。假设一列车经过20站，共1000个位子，可以用一个1000x20的二维数组来表示，每张票就是同一行的一个连续区间[0,20)。假如减库针对这个二维数组来，那只能一次减一个，但可以将这个数组按照热门票（如[3,5),[1,18))拆分为若干个票仓，订票请求根据票面区间去特定的票仓减库，这样可以一定程度上实现并发减库。然后每隔一段时间冻结所有请求，销毁所有票仓重新合成二维数组（其中若干位已经被占用，代表售出的票)，重新拆分为若干个票仓，如此往复。这样的逻辑，我觉得不一定要用多高级的数据库，只要拆票算法做的好，能根据客户请求自主学习，拆出的票命中率高，还是能实现较好性能的。

你如果不是数据库供应商的sales，就是被那些卖big ass服务器的ppt忽悠瘸了。

我老在雄文的第三自然段，就已经预料到了会有数据库供应商不忿，跳出来：

“首先，实际的做法是eventual consistency,而不是immediate consistency。全世界最大的电商Amazon,就是eventual consistency的老祖宗。有的同学提出async processing,算是摸着点儿边了。IBM之流肯定会忽悠你去搞一个实时交易系统，然后通过系统硬件升级狠宰你一刀。注意，这就一个人民群众买车票的系统，我草，别把自己当NYSE了。”

然后再具体看看你的PPT错在哪里：

“但由于订票业务是涉及到金钱与资源抢占的业务，因而一致性是不能放弃的，所以采用NoSQL是绝对不行的。”

这不胡说八道吗？用户从看到页面显示，到下订单，中间间隔几秒？至少几分钟吧？等你敲完键盘下完了单，至少几分钟过去了吧？在那么多人抢票的情况下，你看的页面有票没票的信息早过时了，下的订单只能算意向订单，根本没法保证实时，也没有办法保证你一定能拿到票，所以在我老的设计里，也只是给客户一个回复订单已经提交，至于是否成交，你得查询另一个页面。

你的意思retail客户需要实时数据，几毫秒内实时下单，几毫秒内实时成交？所以你的立论就是错的，往好里说，那是没有把客户需求调查清楚，往坏里说，那就是恐吓铁道部。你自己挑一个罪名吧。

企业经营要计算成本帐，而不是拍脑袋上马新技术。

看来你没有做过要负政治责任的交易系统，从你对NoSQL的态度上就能看出来，估计你对数据库的写入原理也不是太了解。

你应该对做网站的技术很熟悉，但应该对铁路业务不怎么了解。

NoSQL目前而言可以说极不成熟，只适用于对一致性没有要求的场合。无论是实时一致性还是最终一致性。事实上，传统行业中涉及交易业务的大型系统从来不会有人使用10年内的新技术，除非这个人想把公司整垮。不上新技术对他们而言不会导致巨大的问题，无非是每单位成本稍高一些，但采用新技术意味着冒巨大的风险去追求一个很小的每单位成本下降（因为追加新投资，总体成本是上升的，需要通过扩大过模来降低每单位成本）。一旦风险点爆发，就意味着巨大的损失，在私营企业里，就意味着CEO滚蛋，在国营企业中，意味着官帽子落地。事实上，根据我在开源世界十多年的经验，开源产品虽然创意足够多，但真正能够保证质量，懂得业务的产品几乎没有。

因而，铁路方面如果想用所谓“低成本”的产品保证业务和质量，就只能像阿里巴巴那样自行开发来保证，这意味着远比采用成熟产品更加巨大的投资。改造一个极不成熟的数据库产品，没有10个月是下不来的，但这10个月中，各种口诛笔伐造成的间接损失将远超现有的投资规模。更何况，以铁路方面仅仅3亿元的投资规模（软件和硬件）根本支撑不起这样的改造，既是改造只是降低风险而不是消除风险，因为系统成熟性的验证或者需要数学上的证明（比如传统的关系数据库是通过关系代数可以证明的），或者需要时间验证（比如C89的工业运用）。NoSQL目前是两者都不具备的。目前NoSQL主要用于一些允许发生数据错误的场合，比如展示一下商品信息，记录一下图片位置，做个不用负责的论坛等等，都没有问题。但是铁路票务处理不允许这样，除非领导们想集体滚蛋，跟刘志军一个下场。

铁路与电子商务这种新兴行业不一样。电子商务进行技术改造的过程是伴随着营业规模的急速扩大，因而可以摊平投资成本，但铁路不会再有规模的急速扩大，这个成本是很难摊平的。如果刘志军式的大干快上还在继续的话，这种投资扩大倒是可以接受，但当时的情况，由于动车撞车，铁路投资被暂停了。

铁路业务不是CRUD，是Transaction（事务）。无论你如何保证结果的一致性，最后总是要保证一人一票，不能一票多卖，最终这个一致性的保证一定是落到数据库头上的，并且目前来说，只有关系数据库能够在数学上证明自己不出错，这个层面，最低档次的数据库也得是PostgreSQL，不过我不敢保证PostgreSQL就能够保证不出问题，尽管我的所有业务如今都建立在PostgreSQL上了。MySQL不行，因为它事务处理能力太烂（新版本不清楚）。同样，铁路的领导也不敢保证这些解决方案，Oracle出了问题，可以把责任推给供应商，PostgreSQL出了问题，自己承担。

事实上，目前的铁路系统就是放弃了并发性，通过一个后台串行化队列来解决问题，放弃了并行性本身也就放弃了实时性，这种方案历史上叫做假脱机SPOOL，是一种经典的异步解决方案。在票最终被用户锁定之前，所有的订票行为都是有可能失败的。可以看到现在买火车票，当订票之后，不会立刻跳转到付款页面，而是让用户到另一个页面等待付款，实际上等待过程就是交易请求存在于SPOOL的过程，SPOOL将交易请求串行的提交给交易数据库，如果有票，更新状态，让用户付款，如果没票，向用户提示失败。正是因为SPOOL不保证一致性，所以，等票的过程经常会出现各种票消失的故障，因为数据库方面保障一致性，所以不会出现一票多卖的问题。

互联网软件行业拍脑袋技术方案是十分危险的，这些拍脑袋技术方案严重的损毁了中国软件从业人员的信誉，所以很多女子不愿意嫁软件男。中国银行业本世纪初很多系统开发都是外包给软件行业做的，也是由于质量太烂，不懂业务，近些年都下线了，新业务系统都改由银行内部自己培养的软件人员来做。纯软件人员基本上已经被轰出了银行业。铁路行业看来是从开始就不信任纯软件人员。

目前，还和中国还和软件外包业合作的传统行业我接触的主要有电力、政府，并且现在这两个行业信息化改造投资巨大。如果软件行业的人员继续现在这样脱离实际业务需求和成本考量，空谈技术方案的话，被懂业务的内部人员轰出这两个行业是迟早的事情。这些年，我已经见识过好几个软件外包解决方案，吹得天花乱坠，实际对业务处理的一塌糊涂，最后被轰出去的案例了。但软件人员总是不服不忿，总觉得自己的方案是最先进的，于是四处抱怨，比如攻击铁路部门，银行部门搞内部消化等等，几乎很少有反思自身问题的。

中国的软件外包业，如果想继续发展，就一定要向传统行业渗透，辅助改造传统行业。这就要求从业人员必须沉下心来去学习具体行业的相关业务知识，而不是搞什么google崇拜，Amazon崇拜（软件外包行业的现状）。中国很多行业的业务数据规模都是全球最大的，能够将这些问题处理好，拿出国外就是最佳实践，崇拜某些外国公司没有太大意义，要知道，这些公司成功的背后，也是巨大的投资，并不是表面上看着这样简单的。淘宝为了去掉IBM，Oracle，EMC，投资了好几亿进行改造，在支付宝核心交易事务这一块仍然不敢完全放弃掉Oracle，当然外围业务系统很多都采用巨额改造后的开源解决方案了，结果改造后我就碰上过重复扣款的问题，为此阿里巴巴每笔重复扣款都要支付数百元的赔偿。

铁路行业对系统质量的要求是非常高的，不了解的可以看看EN50128规范，指针，多态这些都是不准用的。电子票务系统虽然不需要遵守这个规范，但铁路部门对质量的要求是深入骨髓的。而软件外包业空谈技术不重质量的名声很出名，所以人家不将项目外包很正常。

了解关系事务数据库对一致性的处理可以参考任意一本数据库的说明书。学习数据库的一定要了解这个原理，了解了这个原理才能理解一致性保障的艰巨性。推荐参考PostgreSQL的用户手册，中文版英文版皆可。

我还以为大家在谈技术。

你搞销售的吧，要不就是做外包的？外包公司嘛，自己完全没有开发能力，纯粹的堆代码做业务逻辑，简单地说就是做field mapping的，没有见识过什么叫真正的软件开发。而且还是在国内干，自己开发水平很低，完全依靠厂商，处于用户态。啥数学证明？现在Wall street的trend,是big data,Memcache,MongoDB，Hadoop/HBase,Apache Kafka,而不是EMS/Oracle。大家都是搞交易系统十几年的老鸟，你这开口闭口政治责任的，糊弄一下外行差不多。Knight Capital是做HFT的，他们的cache就是自己开发的。

Postgresql,我不说别的，你看过那个公司用postgresql来处理大数据量的？笑掉大牙。

本想和你认真探讨，可是看来，跟你分析问题，写了也白写，和你说了半天，只看到一堆技术名词，没有看到一个切实可行的能够具体的业务的解决方案，各种技术的优劣利弊也没有任何评价。难怪SUN垮台了，估计就是被所谓的技术人员搞垮的。

我从软件行业出身，接触过金融、电信业务，现从业电力行业，参与过很多外围业务系统的开发和部署，深知一个系统从技术方案到实现远不是几个技术名词的堆砌就能解决的，需要解决实际问题非常之多，像你这样的只讲名词，不讲原型和业务解决方案的，在银行、电力系统里都是直接轰下台，根本不会有人在乎的。

从你说话的内容看，就能够估计出你大约处于一个什么层次。和你探讨问题简直毫无收获。以后不会再回应你的质疑。

希望铁路部门能够采纳你的有效方案，证明你的方案是正确的。投标去吧。你更适合去做销售，因为你比我见过的供应商更加会忽悠名词。销售的典型特点就是：脱离业务讲技术优势，堆砌名词。

实践是检验真理的唯一标准

其实就是一个请求分流的问题。