主题：【原创】好吧，给一个铁道部订票系统的正确答案 -- 布老虎
重做业务流程也是个解决办法。所以这其实不完全是个技术手段能解决的问题。所以他们两个都不能说错。brain storming嘛。
很显然纯coder的思维是不能解决这个问题的。
其次我觉得在这个问题上讨论技术没有什么意义，或者说，太低级。
简单解释一下低级，就是方法有很多种，偏要争哪种好这个我觉得太无聊了。这个是出钱的人说了算了的。适合的才是最好的。
即便从技术上，.net/java/ejb/spooling/acid/开源好不好这种也太泛泛而谈。
泛泛而谈有什么意思呢？对吧。直接略过吧。
不过你还提到QA,release,责任等点，有那么点意思了。很多问题都是到发生了再来讨论技术可行性，晚了。好好盘算下一个项目吧。
我老的结论是，你研究了很多技术，很好很上进。多半发给你的话，要推翻重来，也报个2000万。但是想过客户为什么不一开始就去找那些经验丰富的人来给他做方案呢？
搜索了一下，2012年春节日均售票700万。
由此想到虽然这个业务的特点是高并发高实时但是数据量是很低的。
（请不要争论到底是很低还是低还是中，反正我觉得很大众吧）
而且这700万还不是在时间上平均分布的，而且网站还允许每日停机维护。
所以我就那么一搜索内存数据库了。
这里不提sqlite，没文档。
有个叫extreamdb的，8并发每秒写70万条数据，4并发每秒删40万条数据。可以满足高实时了吧。
而基于内存和磁盘的solid db8线程每秒也可以插入5万多数据。
测试规模在1000万条数据。
所以我觉得可以解决这个问题了。其实我顺带搜了一下当时的抱怨，其实很多纯粹是可以无难度避免的。他们的主要问题还是缺乏设计这种系统的经验。
最后我不得不说，客户既有系统做的烂我们才不断有订单。大家懂吧。
完全同意。国外也是如此。
使用免费开源软件作为这样关键系统的核心是不可想象的。用硬件来类比的话就好像不去找sun买正规的服务器以及维护合同，自己跑去电脑城买一堆散件来攒个机子在上面跑实时交易系统。
每年投入巨资专业维护的oracles数据库，仍然时不时地被各种不可思议的问题击倒。关键交易系统数据库倒个半小时实际经济损失搞不好就超过整套系统的建设成本了，更不用提隐含的声誉受损了。
使用免费软件的方案在讨论的第一分钟就会被枪毙。
现实是购票系统在这几年的黄金周和春运都表现不佳，好几次在高峰时段几乎没法用，问题一堆一堆的 —— 请教哪位同志出来负什么责任了？
你们好像从来没有遇到过必须保质保量完成的项目。
很多帖子一提到搞技术就张口结舌，结结巴巴，含糊其辞，一提到背后勾兑捣浆糊就兴奋异常，甚至说整个项目的成败决定于undertable deal，技术无关。
国内的这些误解和恶习，全是从外包过来的吧。真正做过软件开发，特别是公司内部开发的，哪有什么勾兑，哪有什么甲方乙方？必须完成，不折不扣，拖延一点也许有关系，看竞争对手网站的情况。如果竞争对手网站上了这个featue,你这边还在唧唧歪歪，那就死定了。
你们当真以为技术没有差别？真是黑老子一跳。技术水平的差别直接导致整个项目完蛋的，远的有铁道部，近的有obamacare。
Oracle没有在大数据上任何有意义的产品。目前的大数据产品都是基于Hadoop/Storm，全部开源。
re-invent the wheel了。
In memory db早就有了，你说的是cache还是有persistent capability的db? 简单举个例子，你说的是memcache还是CouchDB?
In memory db要有条件，很苛刻。首先你不能crash,或者有live-live the failover. 道理很简单，你如果crash了，重新启动，要多长时间来reload memoery？
MongoDB/Cassandra之类的key-value store, 首要条件就是所有的数据能够fit into memory，那么就有了很多sharding, failover，read/write separation的设计，来scale out。
我早就指出，这帮人毫无正常的软件开发/测试/发布SDLC的概念，没有正确的测试和发布步骤 - 比如最基本的常识，从一个路局开始，逐步增加路局数量，这样即使有问题也会提前发现提前解决。
拿所谓的政治责任来扇呼，唯一的目的就是用不可知论来吓唬不懂技术的领导，不做任何系统设计（或者这帮人根本设计不了任何可靠的系统，或者故意不做任何设计），完全依靠硬件升级和设备厂家，从而大幅度提高系统成本，把根本用不到的巨型服务器卖个好价钱。从甲方乙方来看，都非常可疑。
简单地说，他们不知道这个系统会出什么事，然后让领导签字买专用设备，理由是，如果出了什么事，厂家负责。
如果领导不傻，一句话就能让这帮人现了原形 - 这系统放上去，你居然不知道会出什么事？
我都不知道在跟一群什么人在讨论问题，这显然不属于信息“技术”版。
但是你这么说是不大可能和客户一起坐下来讨论问题，解决问题的。
对开发人员来说，能负的，就只有技术责任。
但是对客户来说，是有政治责任的。
这中间的区别在于，这么说可能有点冒犯：所有的只能负技术责任的人，都是在向需要负政治责任的人，讨饭吃。
因为决定项目给谁，不给谁，技术走 A ，还是走 B 路线，就是一个政治决策过程。当然，这个政治的级别很低，低到往往只需要在两三家做权衡就可以了。
但是因为谁做的决定而出了问题，比如春运售票，那么，技术公司没有人能承担责任，或者会承担责任。因为这个责任太好推卸了。如兄台在楼里洋洋洒洒的技术分析一样。
但是这些都没用。因为所谓的政治责任就是在一定的时间里用替罪羊来尽快地平息事态，并且以最小的代价缓解，注意不是解决，而是缓解问题。
在这个时候，技术，真的不是首要考虑的方向。同时，外面的技术（团队）的的确确就是不如内部的技术团队能够理解，行动，来搞定事情。
这么说可能会让兄台不喜欢。但是还是那句话，你厉害，我承认。但是我不找你，可以吗？
没有任何冒犯之意。见谅。
我所在的公司有两句口号，我很欣赏：
1，我们就是尽量以我们的能力帮助客户做他想做的事情。
2，这（客户成功）就是我们为之而奋斗的时刻。
当然不是说任何事情都完全依着客户的要求来。这里边有基于我们自身的基础/储备和优先考虑的情况，但即便如此，认真理解客户的需求，尽可能地为客户提供他需要的帮助，还是我们工作的出发点。
我们是在客户那里讨饭吃的。这并不是每一个技术人员都清楚的事情。
有点假大空啊。。。
铁路业务我不熟悉，但是最起码的一点，分步走就牵涉到新系统和老系统界面的问题。按照个人在制造业的一些经验，老系统我估计数量是上千的，这个界面的开发开销应该不比做个新的低。
你说分步走是最基本常识，我的感觉是你可能缺少对业务的最基本常识。。。
个大五十大板之前，先拍拍马屁，让你们不要觉得那么痛。
整栋楼里，有两个跟技术无关的观点我非常欣赏：
第一个是布老虎提出的要预付款，才能买票，这个可以从战略上有效扼制黄牛党。
第二个是红黑客提出的企业级数据库的说法，以我对国企的观察，任何采购，都必须有人要负责，一般来说，象Oracle，IBM这样的供应商，机会大很多，理由是，出了事，可以找人做售后支持（难听一点，就是找人背锅）。提出这个说法，说明红黑客的政治敏感度很高。
要打老虎屁股的有几点：
其一，是他对.Net的蔑视。我就举个例子吧，澳洲4大银行之一的Commonwealth Bank的网银, 就是用asp.net开发的，200多万用户吧，他们分行的客户管理系统叫CommSee，用C#开发的，应该至少也有好几万个用户吧。
至于他说的这句话：
我要摸摸虎头，说，老虎，你没看过这几本书吧？
Essential .NET, Volume I: The Common Language Runtime （Don Box , Chris Sells）
The Common Language Infrastructure Annotated Standard （James S. Miller, Susann Ragsdale）
Inside Microsoft .Net Il Assembler
by Serge Lidin
（我承认，我只看过第一本，获益非浅，呵呵）
其二，他批评红黑客讲政治，不讲技术。这说明他对国企，尤其是铁路这个级别的央企缺乏理解，到了这个级别国企，100%是先讲政治，再谈技术，他完全不知道，能够拍板的人，对采用哪种技术，是7窍通了6窍的。
要打红黑客的屁股，主要是他过于贬低开源数据库的能力，我个人认为MySQL经过这么多年的发展，应该算是相当成熟的了。虽然，要说服铁路部门用，估计不大可能，从技术上讲，我认为还是堪当重任的。
好吧，最后说说本厨的看法：
1. 搞开发，跟厨师烧菜差不多，能否做一份好菜上桌，主要看厨师。搞这个订票系统，主要就看铁路的IT部，是否人强马壮。从之前的系统来看，大家就不要对这个厨师有太大的期望了。
2. 我怀疑最终会外包出去，国内几家，腾讯，淘宝，百度等，都有技术能力。讲政治的话，未必会直接外包给Oracle，IBM。配合支付的话，我觉得几大银行也可以胜任。
3. 开源的东西，不是不能用，但要省这个钱，不容易，没有强而有力的技术团队支持，很容易得不偿失。
4. 天马行空的话，还有一个省钱的办法，能否移植一下国内的内陆机票订票系统呢？
好了，说完了，准备挨砖头了。。。
有些车次是动态调整的，尤其是春节高峰期。
事先跟旅客说清楚具体时间可能会临时调整，相信旅客也能理解。给定一个时间段基本上旅客不会有太大的意见。
因为有了排队机制，排队的人多了，也便于安排临时列车。这其实是优点。