12306系统的主要问题集中在单个处理节点的处理能力以及系统总线的峰值吞吐量上。而12306已经将数据库放在了内存上，而每个节点的内存容量达到了1TB的量级，从目前的情况来看，这已经是目前IT的最高水平，短期内再无其他办法。

自从12306购票系统上线以来，春运期间的崩溃、卡死、页面无响应就伴随着12306的成长。当然，随之而来的便是普通百姓的一片嘘声和所有IT媒体对铁道部IT架构的各种质疑。之后，各种技术大牛和媒体都开始质问12306，为什么不用IBM的解决方案?为什么不找阿里巴巴来做?为什么不增加服务器和网络带宽?面对几乎一边倒的口诛笔伐，一位名叫王强的网友在日前给出了自己的分析答案。

12306IT系统：

12306以前的IT系统主要采用Superdome小型机(具体型号不详)+HP-UX+Sybase ASE数据库。但在发现性能不足之后全部改为x86+Linux平台，基本配置为(大约)17台多路至强E7服务器(具体路数不详)，每节点1TB内存，而数据库则应该还是Sybase ASE(只不过数据库全部放在内存中运行，想要换数据库难度太高，停机时间太长)。

12306系统在2013年春运中的峰值负载约为11万TPS，新的系统在2013年虽然时有崩溃，但都能在短时间内恢复，而这也说明新系统基本抗住了2013年的春运压力。11万TPS的水平与2012年淘宝双11时水平相当。

12306痛点分析：

从12306在2013年春运高峰时每日放票400万张的水平来看，12306虽然在总量上不及13年淘宝双11的水平，但因为12306放票主要集中在10个放票时段，而余票在每个时段刚开始的3分钟内就能够基本售罄，所以12306所承受的压力基本可简化为30分钟内承受300多万的放票，当然，还要有更多的刷新和查询请求。如果以这个标准来衡量，12306所面临的压力堪称全球最大。

另外，12306的每一次出票都会对原有数据库进行更新，交易关联度更大。而淘宝双11的交易则分散在了众多商家中，虽然每次交易也会对数据库进行更新，但其密集程度和关联程度仍不及12306.

为什么不用IBM或者Oracle系统?

这是个尖锐的问题，抛去信息安全和贸易保护的因素不谈，王强给出的答案是IBM Power系统无法与12306现有的系统做到灵活扩展，升级也无法做到不停机。另一方面，IBM Power解决方案在金融方面表现突出，但针对12306这种典型的票务系统，优势则并不明显。当然，价格因素也必须考虑在内(以经验来看，通常小型机及其他核心系统每年的维护费用约为整套系统采购价格的20-30%，甚至更高)。而Oracle的解决方案也有着类似的问题。

王强表示，实际上12306在之前就已经接触过包括IBM和Oracle在内众多全球顶级IT解决方案提供商。但这些提供商纷纷以各种理由拒绝了合作(也包括其解决方案在灵活性、扩展性等方面不符合12306需求的情况)。

为什么不让阿里巴巴来做?

作为国内IT应用水平最高的公司之一，12306当然也不会忘记向阿里巴巴取经。王强在文章中表示，阿里巴巴团队实际上已经参与到了12306系统的建设中来，并且帮助12306构建了其排队系统，这一系统对于帮助12306系统免于彻底崩溃起着巨大作用(免于崩溃指的是系统后端的数据库等核心系统，而对于前端的卡死和崩溃原因目前仍没有确切的定论)。当然，由于两种应用本身的区别性很大，阿里巴巴团队也没能在更大的层面上帮助12306。

怎么拯救12306?

王强在文中并没有直接给出这个最核心问题的答案，不过从以上的分析来看，12306系统的主要问题集中在单个处理节点的处理能力以及系统总线的峰值吞吐量上。而12306已经将数据库放在了内存上，而每个节点的内存容量达到了1TB的量级，从目前的情况来看，这已经是目前IT的最高水平，短期内再无其他办法(12306采用了Pivotal的GemFire分布式内存数据平台，该平台虽然宣称可以通过增加服务器规模线型提升性能，但从实际的情况来看17台多路E7应该就是其性能上线了)。

客观来讲，王强所给出的分析还是非常理性的，而就目前整个业界的IT水平来讲，12306确实已经站在了最前沿，虽然其效果仍不够理想，但其努力仍然是值得肯定的。相信随着单个处理器性能的增强，内存总线带宽的增加，数据中心网络带宽的增加以及延迟的降低，12306的表现会越来越好，当然，这个过程可能会比我们所期望的要漫长很多。