世界最大规模人口迁移——“春运”
到底有多夸张？
你在订票的同时
有多少人在跟你一起订票？
下面有请 Mr.大数据 ！
2016年12月15日
开始发售 2017年春运车票
单日全渠道最高发售车票共1239.2万张
互联网发售峰值 933.2万张
登录人次 8357.1万
高峰售票速度超过 1000张/s
PV(页面浏览量)峰值 426.2亿
那么，从互联网售票的出现，到现在单日近1000万张车票的售出，12306 经历了怎样的变化呢？
12306的出现
12306互联网售票系统是基于中国铁路客票系统这一核心系统构建的。2011年底，12306开始发售全路列车车票，互联网正式成为铁路售票新渠道。
建设之初，系统设计售票能力为120万张/天，极限交易能力为34张/s。
!!! 2012 年春运期间，持续的高并发访问使系统在多个方面出现性能瓶颈。
第一次优化
优化后，系统设计售票能力为500万张/天，极限交易能力为300张/s。
2013年春运，12306网站最高日售票量达到364 万张，占全路售票量的40%，售票量为2012年春运最高峰（119 万）的3倍多。
!!! 2013 年十一黄金周，12306互联网售票量达到了460万，再次接近系统处理的上限，且高峰期外网入口带宽紧张，已不能满足互联网售票量进一步提升的需要。
第二次优化
2013年底启动第2轮架构优化，优化目标旨在提高系统的安全可靠性，以及具备在高峰期处理容量的弹性扩充能力。
优化后，系统设计售票能力为1000万张/天，并在2015年春运高峰时段，实际售票速度超过了1000张/s。
2016年春运售票量最高达到642万张/天，2017年更是高达933万张/天。
具体演进过程
初始架构
独立业务分区：缓存服务、用户管理、车票查询、订单及电子客票处理
三级网络安全域：外网、内网、客票网
数据库：传统关系型数据库
问题来了
1.高并发的查询请求导致车票查询业务分区负载过高，造成AS查询线程池拥堵；
2.放票时高并发的下单请求导致订单/ 电子客票数据库负载过高，造成AS及inetis交易线程池拥堵；
3.AS线程池拥堵进一步造成Web对外服务线程拥堵，影响页面打开及业务逻辑处理；
4.内外网安全平台上在活动及新建连接过多时性能下降；
5.订单/电子客票数据库负载过高时，对线下车站的换票业务产生影响；
6.为减轻网站压力，网站被迫降级运行，限制在线的登录用户数量，造成部分用户不能登录网站。
总结主要原因：由于车票查询以及订单/电子客票业务分区处理能力不足，造成高峰期高并发访问请求下响应时间过长，加之各个业务分区未能很好进行隔离，导致系统由内至外产生“雪崩”效应，造成网站拥堵，影响用户的购票体验。
第一次优化
优化重点：提升车票查询和交易处理的响应速度，以降低查询和交易的延迟；同时尽可能分离核心业务，减少业务环节间的强关联。
1.使用内存计算NoSQL 数据库取代传统数据库，大幅提升车票并发查询能力；
2.构建交易处理排队系统，系统先通过队列接收用户的下单请求，再根据后端处理能力异步地处理队列中的下单请求；
3.对订单/ 电子客票进行分节点分库分表改造，线上相关操作按用户名HASH的方式被分散到各个节点和库表中，有效提升了核心交易的处理能力并具备继续横向扩充能力；
4.对订票、取票操作进行了业务分离，对订单/ 电子客票生成和查询进行了读写分离。
第二次优化
优化目标：旨在提高系统的安全可靠性，以及在高峰期具备处理容量的弹性扩充能力。
1.构建了用户和常用联系人内存查询集群，由用户数据库向集群实时同步数据，并实现了读写分离，提高了相关业务的处理性能和可靠性；
2.构建中国铁道科学研究院第2生产中心，与既有的中国铁路总公司第1生产中心间实现双活，提升网站的安全性和可靠性，并将订单/ 电子客票集群的处理能力提高1倍；
3.在公有云上部署车票查询服务，通过策略配置可随时将车票查询流量分流至公用云，以缓解在售票高峰期网站的处理资源和带宽压力。
【参考文献】朱建生, 王明哲, 杨立鹏,等. 12306互联网售票系统的架构优化及演进[J]. 铁路计算机应用, 2015(11):1-4.
未来的12306
还会有更多变化
想想七八年前拎着小马扎
去排队买票的艰辛
小编相信在以后
无论是买票、取票
还是进站、乘车
都一定会越来越便捷
你们觉得呢？
（内容来源于“铁路计算机应用”微信公众号）
↓↓更多内容请点击下面“阅读原文”获取
▪
