12306铁路订票系统小思

最近坑爹的12306系统引起了全体网民的讨伐，而有趣的一幕是广大程序员们觉醒了，大家从技术的角度讨论的热火朝天，由于买火车票与每一个人息息相关，大家化网站的优化为己任。毫不夸张的说，此次12306事件，引发了IT行业引发了规模空前的，关于网站大规模并发处理技术的大讨论，我总结了一下有一下几个方面：

网站出事的原因的分析及对策：
1.QQ，淘宝，在线量比网站还大，为什么12306做不好，没有进行性能测试，而且工程师太差劲了，请一些牛企的技术专家来即可解决。
我认为请牛企的技术专家来也未必能解决好问题，为什么？在这种系统架构下，如此大规模的并发，我认为国内还没有网站经历过。啊，怎么可能，你可能会说QQ不是号称几亿人同时在线吗等等疑问？要知道，类似于QQ或者网游在线用户这种情况与12306的情景有着本质的不同。因为前者号称几亿人在线，可是大部分在线的人不是同时进行操作，或者说进行某一项事物处理，所以实际的并发数要远远少于线上的人数，设想如此大规模的并发量，我想没有哪个网站敢保证平稳应对。

对于性能测试，我想铁道部不会傻到没有进行压力测验，只是实际最终的并发数恐怕铁道部自己也没有预想到，或者系统没有做好这种级别并发数下的应对准备。

所以，对于这种海量的事物处理，目前还没有很好的解决方案，Hadoop可以,它是一个能够对大量数据进行分布式处理的软件框架，但是Hadoop本身应用未必容易，铁道部也不会那么容易就应用这么庞大的改动。


2.铁道部的票务核心系统速度慢，不完全是网站设计的问题。要改进应该先对核心票务系统改进。
如果真的是票务核心系统的原因，那恐怕要解决就不是那么容易的事情了。

首先，铁道部不会让外包公司轻易的涉足核心系统，目前合作的公司如太极，网宿科技都还只是硬件集成，类似于中间件，软件，数据库，运维均无权涉足。显而易见，如果让外包公司涉足，那么铁道部这个大黑窝恐怕还不知道要整出多少黑幕，到时候恐怕就不是一个订票系统的问题了，整个铁道部恐怕都要变天吧。

然后，如果要重构整个核心票务系统，那么其工程量将会及其巨大，所牵涉到的方方面面很难协调，况且，目前铁道部自723事故之后，本身的预算收紧，很难说有这个资金来进行系统重构。而且重构本身也不完全是钱能够解决的，软件方面的问题，钱不是最重要的，如果钱能解决，那么这个所花的钱也是不可想象的。

3.系统的购票流程太坑爹，设计了一个大事物处理，另外涉及到YI，允许重复登录，停留时间无限制，采用CS模式等问题。应该改进购票流程，先充值，再购票，类似于网游充值。如果没票了，再退款。关注细节，不允许重复登录，限制网站停留时间。
网站实在太多地方需要改进了，我认为大家提的意见都很正确，将付款与查询，订票分离，而不是一个超大的事物搞定整个购票流程，我觉得这样很容易出现死锁的问题。对于UI，我倒是觉得不是首要解决的问题，因为对于大家来说，能买到票就行了，关键是速度要快，不在乎页面有多难看，UI的问题可以在后期不断改进。如果采用分离模式，停留时间问题也就迎刃而解了，用户在较短时间内可以完成查询，订票操作。而现在以我切身体验为例，买一票在系统里停留的时间几乎有将近1个小时，这样极大的浪费了系统资源。

对于CS模式，我觉得CS模式能很大程度上分解系统的压力，很多操作占用客户自己的电脑。但是很重要的一点就是，它的安全性，如果因此而造成购票的不公平，我想着比买不到票还严重。另外，做成客户端，它的后期升级维护也存在很大的问题。所以我不赞成用CS模式。