前言：
最近经常看到买票难，作为搞技术的我TMD的骂一次：
票会增加吗？总是有人能买到，有人不能买到；
就不能换个思路设计订票系统。
要是我是什么什么的来着，早已经实现通过手机短信、网站就能轻松买票了；
还顺便将手机实名制给实现了。
正文：
不知是我想简单了，还是专家们想复杂了。
铁道部的专家还停留在线下售票方案中拨不出来；
线上售票系统简单得多了。
骂完铁道部后，提供一简单又可行的解决方案。
查询余票、防止超售、防止黄牛，一般的设计思路是有难度，
换个思路，TMD太简单的就能搞定。
一、总体方案
1、正常情况：预订交钱-->后台自动验证规则-->不符合购买限制的钱原路退回-->
-->提醒用户预订成功（但不一定有票）-->运输资源出来，根据先到可先得+优化级的原则分配
-->短信通知用户取票
２、用户不取票：没有关系，因为铁道部已经收到钱，所以你开车前两小时取即可。
多方便啊，就不用为了票多走一次车站。
３、用户退票：春运有人退吗？平时要是退了，就退吧
二、前台网站设计
只需要预订，根本不需要查余票什么的。所以很简单的架构就能搞定，甚至不用CDN
三、后台设计
预订后，后台慢慢处理，看资源情况增加服务器。即使后台的服务器挂了，前台用户也感觉不出来。
运输资源出来，看有多少是分配给网上订票的，依规则分配即可。
这样后台的架构要有多灵活，就可以设计成多灵活。
后台由验证服务器+分配服务器+取票及跟踪服务器组成。
具有分配资格的，满足了身份证唯一、已付款、优先级等等要求了；
而且是一票一票分配的，根本就没有什么复杂的逻辑处理，也没有什么数据库表锁；
因为能分配的已经满足了锁的要求了，用单线程分配就好了。
２核的一秒就可以处理1000张票以上。
四、可能的问题
１、有存在海量的处理的情况吗？没有，预订对数据只是增加操作，不需要扣除数量锁表
２、有峰值压力吗？没有，预订时要处理的事情很少很少
３、能不能订到票，心里没底？预订和抢票，没有区别啊，
关键一点的是，预订可以有复杂的预计，比如允许自动安排下一趟什么的；
多灵活啊。也不要做哪些没有意义的重复提交。
４、如果铁道部的内部人员想作弊，采用什么方式都可能存在作弊
五、优点
１、能提前１０年预订都没有问题，只要铁道部和旅客愿意。将来的目标发展为：个人旅行管理系统
２、前台轻量，爱怎样扩展就怎样扩展
3、后台爱怎样处理都行，而且可以很容易监控，有异常还可以人工偷偷处理一下，用户根本感觉不到
４、实际上这样一套系统上线，在家中买票，要坐车再去取票就可以了。不够铁道部的关系人少了点代理收入。
经以上分析，结论：用Asp.net+SQL２００８ 就可以轻松实现。特别是后台，用C#.net开发绝对是优势。