12306并发解决

前言：

12306 互联网售票系统在 2011 年下半年开始上线使用，但在 2012 年春运期间引发无数的争议。在 2012 年春运后，12306 项目承接单位与多家 IT 公司联系，经过多次论证和 POC 测试， 最终引入分布式内存运算数据管理云平台 - Pivotal Gemfire 做试点，用以提高 12306 系统性能，解决“高流量和高并发“的难题。

高流量高并发是指某特定时间段的海量请求，根据过去的经验法则，高并发是指访问流量是平常流量的 3-5 倍；但由于互联网和移动设备 apps 的普遍化，电商网站的促销模式“11.11“，或是厂商的“饥饿营销“，都会衍生“秒杀“现象。所以过去的经验法则用到 12306 春运售票系统，往往是远远低于实际的的流量。例如，12306 平常一天的 PV（page views）值大约是在 2500 万到 3000 万左右， 在 2015 年春运高峰日的 PV 值是 297 亿，流量增加 1000 倍，这样海量的请求，假如不能在短时间内动态调整网络带宽或增加服务器数量，就会造成网络阻塞或是服务器性能无法满足要求，甚至使整个系统不稳定。

12306 成长之路

短短的 3 年，从 2012 年春运到 2015 年春运，12306 网站从 10 亿的 PV（page views）值增加到 297 亿 PV 值，PV 值成长 30 倍；网络带宽从 1.5G 调整到 12G，带宽成长 8 倍；而 12306 的售票量从 110 万增加到 564 万 ，成长 5 倍。出票处理能力从 每秒 200 张提升到 每秒 1032 张，也是 5 倍的成长。

PV 值的增加是与放票的次数和可出售的票量有关系，例如，2015 年 PV 值是 2014 年的 2.3 倍, 原因是放票次数多了 5 次“秒杀”，另外增加 12% 的售票量。由此可见，互联网流量 PV 值的增加速度远远高于售票量增加的速度。

高流量除了代表网络容易造成阻塞以外，系统服务器也会面临更高的 CPU 负载，在此情况下又该如何应对呢？是选择基于原来系统框架上购买更昂贵的硬件做“scale up“升级呢 ？还是选择购买低成本的 x86 服务器，进行”可扩展云平台架构“ scale out 的改造设计呢？12306 互联网购票系统的改造给我们一个很好的案例参考，也让政府单位和企业进一步了解了具体是如何实现的。

12306 改造的关键技术– 建立可伸缩扩展的云应用平台

2015 年 12306 网站顺利过关，没有“瘫痪”，是值得庆祝的。根据互联网上的新闻，中国铁道科学研究院电子计算技术研究所副所长，12306 网站技术负责人朱建生说，为了应对 2015 年春运售票高峰，该网站采取 5 项措施：一是利用外部云计算资源分担系统查询业务，可根据高峰期业务量的增长按需及时扩充。二是通过双中心运行的架构，系统内部处理容量扩充一倍，可靠性得到有效保证。三是对系统的互联网接入带宽进行扩容，并可根据流量情况快速调整，保证高峰时段旅客顺畅访问网站。四是防范恶