回顾12306 成长的烦恼

（1）网络阻塞是个门槛

网络是进入12306征程的起点，网络带宽快慢往往决定“秒杀“的结果，这在很多电商网站促销时时常发生， 因此12306也无法避免。下面数字是由互联网收集得到的，可能有偏差。但我们尽可能根据这些数目字来解析数年来网络原因发生的问题。

• 2012 年：12306 第一次在春运使用， 网络带宽1.5G，可以支持最大的PV值是11,250；根据报导，此系统有10,000人的登陆限制， 假如每人每秒点击一次的话，理论上是可以勉强支持正常的点击量。

但在购票尖峰日，有上千万的网民第一次上网购票，在无法登陆的情况下， 用户不断刷取首页，或是已登陆者无法得到系统的及时反应，不断点击页面，产生大量的请求，造成网络和系统的高负载，导致崩溃。

• 2013年 ：宽带增加一倍到达3G频宽，有20万用户登陆的限制，采取10次放票，分散流量，防止买票过度集中；但不幸的是“刷票软件”横行，每秒可以刷票数十次到数百次，高峰期有25万的PV值， 远远超过带宽的最大理论值 22,500 PV。

• 2014年 : 宽带增加到达5G，16次放票，有屏蔽刷票软件抢票的设计，有效阻挡90%的点击，但实名制有漏洞，每秒还是有15万次的浏览需求，远超过37,500 PV的的理论带宽承载量。

• 2015年 : 12306有21次放票，增加带宽到12G，手机订票（流量小）分担25%的12306售票，解决实名制的问题，可以阻挡95% 刷票软件的点击量，每秒最大有117,800次的浏览请求，此数目字已经很接近理论带宽承载量117,400 PV值。

根据上述解析， 2012年 – 2014年春运的网络带宽给12306带来很多问题。根据网民的反应，在2015年12306带宽在 12G的情况下，虽然稍微有点卡， 但是大致的反应还是不错的。此轮点与我们的推论是大致符合。

 

	尖峰日 PV值	放票次数	尖峰每次放票 平均PV值	网络带宽	带宽最大理论PV值/秒	浏览请求最大PV值/秒
2012	10亿	4次	2.5亿次	1.5G	11,250	10,000
2013	15亿	10次	1.5亿次	3G	22,500	250,000
2014	144亿	16次	9.0亿次	5G	37,500	150,000
2015	297亿	21次	14.14亿次	12G	117,400	117,800

 

1. PV值和放票次数是根据互联网的报导。

 

2. 2013年与2014年的PV值有10倍的差异， 2014年多了6次放票时段，票的出售量增加90%。但在 2013年，极有可能是大部分的票量集中在少数时段就放完，减少多次的“秒杀“发生。

3. 2012和2013年， 12306 没有屏蔽抢票软件的设置。在2014年以后，实现了基本的屏蔽功能。 假设此在2014年可以阻挡90%抢票软件的点击， 在2015年可以阻挡 95%的点击。

4. 在2015年， 假设互联网的平均PV值的数据量是15K byte， 手机上网的PV值是 1K byte，占有25%的流量。

5. 带宽最大理论PV值/秒 ： 1G的带宽是1,000,000,000 bit/second,1 byte = 8 bits.

2015年平均PV值 =11.5K byte （含手机上网）, 2012-2014年的PV值= 15K bytes。

另外，假设考虑网络IP协议交换有10%的损耗。

6. 浏览请求最大PV值/秒：假设在每个放票时段，抢票的高峰期是5分钟（含查询， 下单，付款等操作），在高峰期5分钟的下载流量是整个时段下载总量50%；

再假设有效的浏览下载量是5%上传的请求点击量，换句话说，有95%的点击量被屏蔽，可能是阻挡刷票软件，或是网络阻塞丢包，或是系统忙碌没有反应等等。

（2）服务器集群性能无法伸缩性扩展 

参考互联网上的资料，12306服务器集群是传统的三层架构设计，如果不考虑最前端的F5负载均衡服务器，它是由 数百部 Web服务器集群和应用服务器集群构成前端，64部数据库小型机集群（用于专门实现并行计算每班车次的余票量），和订单处理服务器集群构成后端。从专业的角度来看，此种框架设计是中规中矩的，国内99%的框架设计师都是如此设计。

如前述所提，由于Sybase数据库的原因，此种设计无法做伸缩性的扩展。因此，12306要进一步提高性能就面临很大的抉择。在此，先了解服务器集群性能与实际需求之间有多少差距。

回顾2012年到2015年，12306系统在这3年内有很大的变化。

1. 2012年春运 ：根据互联网上的信息，2012年 12306设计的售票指标是在100万张票的销售，这完全低估了互联网网民的实际需求，在尖峰日，有上千万人登陆。网络带宽，Web服务器集群，应用服务器集群，余票查询/计算集群,到订单处理集群, 这些设备性能完全无法应付高流量高并发的请求。由于极大的低估互联网的需求，造成12306整个系统不稳定。

在12306系统，余票查询/计算子系统是最复杂的， 最耗损服务器CPU资源。在整个客票系统里，有数十条行车路线，有3000多个车次（G,D,K,Z,C,..），5000多个火车站，不同的席次（硬座，硬卧， 软座， 软卧， etc），座位等级(商务， 一等， 二等)，和车票等级（一般，军人， 学生，残障，小孩）等因素，将这些参数换算成数学模型，那可是有数千亿条的排列组合。

 2012年的余票计算系统实际处理能力据估计不会超过 300-400 TPS，而有效的余票查询请求远远高于3000 QPS （query per second）。另外，系统每隔10分钟更新车次的余票，这些余票信息是没有参考价值，因为在10分钟里已经售出数十万张票。如果要满足余票计算的需求达到至少 3000 TPS， 那么12306 需要再增加6倍的服务器，即将近 400部小型机（原有系统有64部服务器）。 

2. 2013年春运：在2012年6月进行第一步余票查询/计算改造，使用Pivotal Gemfire改造后的结果是每秒至少支持 10,000 TPS 以上，此数目字已经足够应付高并发的需求，因此在2013年春运余票查询顺利过关。 由于集群计算能力大增，余票更新缩短到每隔2分钟提供最及时的信息。

在余票查询瓶颈移除后，订单处理服务器的瓶颈就出现在订单排队，网民必须等待数十秒到数十分钟才会得到订单的确认。订单的请求累积高达数千甚至数万个以上，估计当时订单处理服务器的处理能力不超过 200-300 TPS。

3. 2014年：在2013年后，进行“订单分库二级查询”处理，将订单生成与订单查询分开处理。因为订单查询的数量远远超过订单生成的数量。因此， 12306将查询订单的热点数据放在Gemfire集群， 将历史订单数据放在Hadoop集群。如此设计，不但提高订单查询的功能数十倍，而且订单生成的性能至少也提高5倍以上（使用原有服务器）。

4. 2015年：进一步使用Gemfire优化整个 12306系统，总共建立5个Gemfire集群。另外建立三个数据中心（高铁公司， 铁科院，和阿里云），在阿里云上部署数百个虚拟机（有 Web服务器，应用服务器，和余票查询服务器集群）分流余票查询75%的流量，因为余票查询流量占据12306整体流量的90%。

 

	平均每次放票量	尖峰有效余票 计算请求（QPS）	余票计算能力（TPS）	尖峰期订单 处理请求（TPS）	订单处理能力（TPS）
2012	415,000	> 3000	300-400	》 1600	200
2013	265,000	> 3000	》 10,000	》 1030	500
2014	313,000	> 3000	》 10,000	1200	1000
2015	268,500	> 3000	》 10,000	1050	1000

 

在12306系统，余票计算的结果是放在“数据缓存应用服务器”，在2012年每隔10分钟更新每班车次的余票结果。如果新请求与上次更新的时间间隔低于10分钟，数据缓存系统就直接返回上次计算的结果。而在10分钟左右再重新计算新的请求。在10分钟的间隔，服务器集群需要计算3000多个车次的余票结果。自2013年以后，12306系统每隔2分钟更新车次余票结果。

 

使用Gemfire改造后12306的现状和启示

2015年的春运购票期间12306系统的表现是很令人瞩目的，它的效果和影响总结如下：

1. 提供“高并发，低延迟”的解决方案，一劳永逸，不用烦恼后续硬件升级的问题 

2. 通过GemFire多集群技术，实现多重的高可用性，确保高峰压力下和系统异常的情况下保证业务的持续性。

3. 构建一个可扩展的云应用平台架构，灵活和快速热部署的机制，为未来混合云的部署打基础。

4. 余票查询集群性能提升 ：

• 使用数十部 x86服务器 （或是上百部虚拟机）可以达到 10,000 TPS以上，提升原来系统性能达30倍以上。原来的系统是使用64部Unix 小型机。
• 余票信息更新从原来10分钟缩短到2分钟，使信息更有参考价值。

5. 12306“订单分库二级查询”子系统：

• 将订单生成与订单查询分库处理，订单查询性能提高50倍， 订单生成性能提高4-5倍。
• 将热点订单放在Gemfire集群，将历史订单数据放在Hadoop集群。这是快数据和大数据结合的完美案例。

6. 混合云的应用：

• 使用Gemfire改造后的分布式系统，极易分散部署到不同的数据中心
• 例如，余票查询子系统可以独立于原来的大系统部署到公有云上，同时也可以再将此子系统一分为二，将另一部分服务器部署在私有云的数据中心。即按业务需求随时部署所需要的资源，来解决高并发的难题。