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

我也算科班出身，软件开发的专业，也算国内最好的学校之一了。从毕业几乎就没做过什么通用软件，基本上都是定制化的业务软件。开始的时候，想法很简单，客户有什么需求就说，我肯定都给你做出来。后来发现，真不是这么回事。业务人员所描述出来的业务，肯定只是业务的一个表象和片面。如果真的在某个项目里面能够碰到一个啥业务都懂的客户，那真是烧了几辈子的高香了（当然还得祈祷这不是个大忽悠）。所以如何理解多个用户从各自的角度所描述出来的业务，如何理清背后的业务逻辑和数据关系，这真的不是技术精通就能够解决的问题。如果对于业务逻辑没有足够的理解，你会在快上线的时候发现，哎，这个需求当时怎么没说，这个需求你当时说的不是这样啊等等.......。用户不是专家，他不了解从系统的角度都需要了解什么内容，你也很难保证当时说的话真的完全匹配现场的情况。这就需要你对所做业务的一定程度的了解，既要有深度，又要有广度。更不要说，在业务系统里面，同样有那种可能会超出一般技术水平的要求，对于他们可能就是一句话的事情，但对于开发人员真是苦逼大了。

特别对于红黑客所说的后面的政治要求等特殊的背景问题，更是从一立项开始就要充分考虑的因素。这个将会影响到报价，工期，技术方案，项目组织方式，上线安排等等一系列的事情。如果项目经理没有这个意识，基本上不要想做好项目了。而且这不是所谓的中国或者国企特有的，私企也是一样，国外也是一样，看看医改网站就知道了。区别只是在于影响的要素有所不同罢了。

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

看来你没有做过要负政治责任的交易系统，从你对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的用户手册，中文版英文版皆可。