主题：【原创】好吧，给一个铁道部订票系统的正确答案 -- 布老虎
Linux就是开源的，用Linux第一时间枪毙？俺不信。
比如RedHat就是一家对开源软件提供收费服务的公司。事实上是理论上任何人都可以把开源软件打包去卖。
因为程序化交易的发展，有些交易已经是在毫秒甚至更小级别上竞争了。
其它的考虑再多也必然失败。而楼主的方案再差，也是在解决这个主要矛盾。
铁道部和开发者究竟把最终用户放到哪个位置？作为开发者，提升客户的Value，解决客户的问题（当然还要＂顺便＂赚点钱）才是第一位的吧。如果这个主要目标都做不到，其它的说再多有什么用？如果主要目标根本做不到，也许项目本身就不应该立项。
俺只能说铁道部活该挨骂。他们根本就没把最终用户放在心上。对用户流量不论从理论上计算还是从实际情况出发模拟都不是什么大问题。
难道铁道部不是应该想给老百姓提供更好的服务吗？楼主就是在提升最终用户体验啊！
铁道部不通过技术人员怎么知道这个系统能不能满足铁道部客户的需要？这个项目是为了什么立起来的？就是为了找骂？
毕竟春节绝大多数人都是回家的，有很强的统计规律性。其它节日也类似，铁道部有心的话这些年应该收集了不少数据，拿出来分析一下应该很有帮助。
这100个窗口直接开在数据库上，可是要当机的。
正确的办法是把一段时间（比如1秒）的所有请求在RAM里列队，归类，去掉重复的，这才insert到数据库服务器里。“5万5个Transaction”在数据库这边，就是TEMPORARY DB（可以在RAM里）里小小的几个表。数据库只需run几个简单的query，然后把结果返回就完了。
这样数据库在每个时段只需做有数的几个index query，一点压力也没有. 而且load是线性增长。如果你窗口直接开数据库上，那么数据就要跑几万个类似的query，每次都要扫描index，读写的压力不说，cpu和内存的压力都很大。
这玩意儿一看就是单机的，不管怎么把它网络化。
后端服务器先检查这哥们的钱够不够。因为这钱已经存进铁道部的系统， 这就直接在铁道部的数据库里（就叫存款数据库吧）查询就行了，用不着到工农中建的服务器上去做啥web service。钱够了，直接扣就行。简单的按身份证号sharding数据库table就行了，200个MySql serve, 每个32G内存，够全国人民用的吧？全部响应在毫秒级。
如果这哥们钱不够，把请求扔到一个message queueu（就叫insufficient funds queue吧), 然后email 短信啥的就不多说了。
如果这哥们钱够了，先扣钱，然后把请求扔到一个message queue（就叫 seat checking queue 吧），这个queue主要就是占座位了。如果座位被占了，那么就回到存款数据库里把钱退回去。如果座位还有，那么就占座，然后发送两个message, 一个message到另外一个message queue (就叫做cache update queue吧），这个queue的任务是更新第一步里面的cache（看，叔叔没有骗你吧？)。另一个message当然就是发短信确认订座了。 这一步的响应也应该在毫秒级。
您说的这个系统肯定是能实现的。但用户体验也是将是很差的。
买票作为一个流程，对乘客来说在网上买票其实和到车站售票处买票都是买票。对于乘客来说，最重要的是我交了钱就要拿到票。
到车站售票处买票，售票处不能跟顾客说，你先把钱交了，然后我短信通知你有没有票，拿不拿得到票。都是一手交钱一手交票。
同样的，网上售票也不能用这种先交钱，过一阵再出票的形式。这么搞的话，只要有一两次人家交了钱却订不到票或者要重新订票，人家就不会再信任这个系统了。
网上售票和网上售货一样，卖的归根到底也是一种货物。大型的网上售货网站在顾客下订单收钱之前就要查库存。如果库存不足就要立刻通知顾客没货了。
所以流程应当是乘客查询订票-》系统查询库存-》锁定库存-》受理客户支付-》确定客户有钱-》出票。
其他数据库我不是很熟，但当年用过SQL Server,他们可是声称有32,000个User connections，外链出处所以，我估算100,然后每个Transaction的时间是0.1秒，应该算是保守的了。
当然，这样的项目，少不了要做Performance Tuning的。
布老虎的想法应该是，想买票，先充钱，买不到票，可以退款。
事先也可以警告买家，下单时看到有票，有可能下单后买不到票，在一两分钟内可以通知买家。
这个跟网上售货的情况有这种区别的原因，货物可以下单后再生产，春运时的火车票可没办法这么做。
一定要对比的话，可以跟一些网上售卖的绝版玩具对比，但那样的网售产品，大多是拍卖的，你觉得春运火车票，可以拍卖吗？
我觉得买家应该可以理解，毕竟排队也不一定能买到票。
这6.7亿美元的政府项目没有通过竞标，就给了在业界名声不太好的公司做。