5分钟了解 12306售票系统技术架构的演进及海量数据的处理逻辑

大家好，欢迎来到IT知识分享网。

想必大家都在12306APP或着网站上买过票。但是大家知道这个网站是怎么一步步达到目前海量数据的处理能力的吗？下文将对这套系统的技术演进做归纳分析。

12306 互联网售票系统是基于中国铁路客票发售和预订系统（简称：客票系统）这一核心系统构建的。

2011 年 6 月 12 日，系统投入试运行，发售京津城际列车车票；2011 年 9 月 30 日，发售全路动车组车票；2011 年底，发售全路列车车票，互联网正式成为铁路新的售票渠道。2012 年春运期间，由于访问量超出设计预期，12306 网站在高峰期出现了页面打开缓慢、查询和下单报错、后台系统过载等一系列问题，用户体验不佳。春运结束后，研发团队基于新一代客票系统多个科研项目，对系统架构、应用功能以及业务规则进行了持续优化和改进，逐步解决了售票高峰期海量并发访问请求及处理等一系列关键技术问题，大幅提高了系统的处理能力、稳定性以及用户体验。本文将重点介绍 12306 网站自建设之初至今针对系统性能优化的研究与实践工作，以及系统架构的演进过程。

1 12306系统架构及其出现问题

互联网售票系统作为客票系统一个新的售票渠道，建设之初，在借鉴和参考客票核心系统架构的基础上，根据互联网应用的特点，为系统设计了缓存服务、用户管理、车票查询、订单及电子客票处理等多个相对独立的业务分区，以及三级网络安全域，分别是外网、内网和客票网，系统的体系架构如图 1所示。

图1 12306建设初期体系架构示意图

具体实现时，用户管理、车票查询及订单 / 电子客票处理均采用了传统的关系型数据库，其中车票查询业务部署了多套负载均衡工作模式的数据库，订单 / 电子客票处理业务采用了双机热备模式的数据库，上述数据库均运行在小型机平台上。外网的车次、余票等缓存服务采用了基于内存计算的 NoSQL 数据库，运行在 X86 平台上。上线前的压力测试，一笔流程包含用户登录、车票查询、下单及支付等业务操作，系统极限交易能力为 34 张 /s，按高峰期 10 h计算，售票量可达到 120 万张 / 天的设计能力。 2012 年春运期间，持续的高并发访问使系统在多个方面出现性能瓶颈，如图 2 所示。

图2 12306架构在高峰期出现的瓶颈示意图

出现的主要问题包括 ：

(1)高并发的查询请求造成车票查询业务分区负载过高，查询响应时间过长，用户进而反复重试， 造成 AS (Application Server)的查询线程池拥堵。

(2)放票时高并发的下单请求导致订单 / 电子客 票数据库负载过高，引起交易响应时间过长，造成 AS 以及 inetis 的交易线程池拥堵，下单失败后用户 反复重试，从而加剧拥堵。

(3) AS 线程池的拥堵进一步造成 Web 对外服 务线程的拥堵，影响页面打开及业务逻辑处理，造 成页面打开速度缓慢和超时错误。

(4)内外网安全平台上在活动及新建连接过多 时性能下降，也导致 Web 访问 AS 出错。

(5)订单 / 电子客票数据库负载过高时，对线下车站的换票业务产生影响。

(6) 为减轻网站压力，降低查询和下单的请求量， 网站被迫降级运行，限制在线的登录用户数量，造 成部分用户不能登录网站。

春运过后，互联网上也出现了关于 12306 架构的讨论和建议热潮， 通过认真听取各方意见， 梳理上述主要问题的原因和关联关系，结合系统监控数据， 总结出主要是由于车票查询以及订单 / 电子客票业务 分区处理能力不足， 造成高峰期高并发访问请求下响 应时间过长，加之各个业务分区未能很好进行隔离， 导致系统由内至外产生“雪崩”效应，造成网站拥堵， 影响用户的购票体验。

2 系统架构的调整及优化

针对上述问题及原因，将架构优化及重构思路重点放在提升车票查询和交易处理的响应速度，以降低查询和交易的延迟。同时尽可能分离核心业务，减少业务环节间的强关联，具体内容包括 ：

(1)使用内存计算 NoSQL 数据库取代传统数据库，大幅提升车票并发查询能力，车票查询的T PS/ Q PS (Trans action/Q uery per Second )由不足 1 000 次 /s 提升至超过 20 000 次 /s ，RT (ResponseTime)由原来的 1 s 缩减至 10 ms，使用户可以快速 获取到车次及余票情况。

(2)构建交易处理排队系统，系统先通过队列 接收用户的下单请求，再根据后端处理能力异步地 处理队列中的下单请求。队列的下单请求接收能力超过 10 万笔 / 秒，用户可以在售票高峰期迅速完成 下单操作，等候系统依次处理，等候过程中可以查 询排队状态(等候处理的时间)。排队系统中也采用 了内存计算 NoSQL 数据库。

(3)对订单 / 电子客票进行分节点分库分表改造， 将原有的 1 个节点 1 个库 1 张表物理拆分为 3 个节 点 30 个库 30 张表，线上相关操作按用户名 HASH 的方式被分散到各个节点和库表中，有效提升了核心交易的处理能力并具备继续横向扩充能力，使用 户在队列中的订票请求可以得到更快的响应和处理。

(4)对订票、取票操作进行了业务分离，由不同的业务节点(售票节点和取票节点)承载网上售 票和线下取票业务；对订单 / 电子客票生成和查询进 行了读写分离，使用内存计算 NoSQL 数据库集中存 储订单 / 电子客票，提供以 Key-Value 为主的查询服 务，订单查询的 TPS 由 200 次 /s 左右提升至 5 000 次/s 以上，大幅提升了订单 / 电子客票的查询效率。

优化和重构后的架构如图 3 所示。

图3 第1次优化后的12306体系架构

在新的架构中，通过高效的车票查询集群和缓存服务， 用户以较低延迟即可获取到所需车次的余票情况。随后的下单操作(订票请求)直接由排队系统压入队列处理， 不同的车次 / 日期进入不同的队列， 订票请求不再直接面对内网的 AS 和客票网的核心交易系统。

具体实现时， 考虑到车票查询结果有缓存延时，在订票请求进入队列前，还将实时查询车次余票， 确有余票且当前排队人数不超过余票数量时才最终允许订票请求进入队列。排队系统收到请求后，采用动态流量控制策略，即根据位于客票网各个铁路局客票中心的席位处理以及订单 / 电子客票集群处理 的响应时间，向 AS 提交用户的订票请求，处理响应时间放慢，则提交速度放慢，反之则提高订票请求 的提交速度。读写分离，避免了高并发、低延时要求的查询操作影响交易处理 ；售票和取票分离，使网上售票与线下取票互不干扰。优化架构后的系统在 上线前压力的测试中，极限交易能力为 300 张 /s，可以满足日售票量 500 万的业务需求。

2013 年春运，优化架构后的 12306 网站最高日 售票量达到 364 万，占全路售票量的 40%，售票量为 2012 年春运最高峰(119 万)的 3 倍多，各铁路局客票系统以及 12306 网站性能稳定，运行平稳，充分证明了架构调整的有效性。

2013 年十一黄金周，12306 互联网售票量达到了 460 万，再次接近系统处理的上限，且高峰期外网入口带宽紧张，已不能满足互联网售票量进一步提升的需要。此外，作为铁路售票的主要渠道，互联网售票系统单中心运行模式已不能满足业务安全性和可靠性的需求。为此，自 2013 年底起启动了12306 网站的第 2 轮架构优化，优化目标旨在提高系统的安全可靠性，以及在高峰期具备处理容量的弹性扩充能力，具体内容包括 ：

（1）将用户登录及常用联系人查询等业务迁移至内存数据库中，提高了相关业务的处理性能和可靠性。

（2）构建中国铁道科学研究院第 2 生产中心，与既有的中国铁路总公司第 1 生产中心间实现双活，提升网站的安全性和可靠性，并将订单 / 电子客票集群的处理能力提高 1 倍。

（3）在公有云上部署车票查询服务，通过策略配置可随时将车票查询流量分流至公用云，以缓解在售票高峰期网站的处理资源和带宽压力。优化和调整后的系统架构如图 4 所示。

图4 再次优化后的12306体系架构

此次架构优化过程中，完成的主要工作包括 ：

（1）构建了用户和常用联系人内存查询集群，由用户数据库向集群实时同步数据，并实现了读写分离，用户登录和常用联系人查询的 TPS 提升了 50倍以上，消除了业务瓶颈。

（2）构建了第 2 生产中心，采用虚拟化技术与原有的第 1 生产中心组成了双活架构。用户流量通过 CDN 在两中心间进行对等分配（50:50），两个中心拥有独立的 Web、AS、缓存服务集群、车票查询集群、用户及常用联系人集群以及交易中间件，排队系统以主备模式运行，用户数据双向同步。正常情况下双中心双活模式运行，其中任一个中心发生故障时可由另外一个中心承载全部售票业务。

（3）在互联网公用云上部署了车票查询集群及查询服务，由 CDN 完成车票查询流量在第 1 生产中心、第 2 生产中心以及公有云间的流量分配，流量分配可通过动态调整策略在线完成。

在双活架构的建设过程中，将订单 / 电子客票集群完全迁移至 X86 虚拟化平台，并扩充至 10 组节点，100 个库，100 张表。上线前的压力测试验证了系统可以满足 1 000 万张 / 天的设计售票能力，在 2015年春运高峰时段，实际售票速度超过了 1 000 张 /s（约合 360 万张 /s）。第 1 生产中心、第 2 生产中心间订单 / 电子客票集群具备热切换能力，显著提高了系统的故障隔离能力和系统的安全及可靠性。公有云在2015 年春运期间最高分流了 75% 的查询请求，网站对外车票查询服务能力增加了 3 倍。基于 CDN 缓存服务（一级缓存）、双中心及公有云缓存服务（二级缓存）、双中心及公用云车票查询集群（实时计算），12306 网站在 2015 年春运高峰日处理了超过 180 亿次车票查询服务，平均 TPS 超过 30 万次 /s。

3 结束语

回顾 12306 互联网售票系统的发展，高峰售票量由 2012 年春运的 119 万张 / 天，增至 2013 年春运的 364 万张 / 天，系统架构的优化与调整起到了至关重要的作用。2014 和 2015 年春运售票量再次超过500 万和 600 万，最高达到 636 万 / 天，验证了二次

优化后架构的合理性和有效性。12306 互联网售票系统在优化架构的同时，还在核心业务中用低成本的 X86 平台全面替代了原有的小型机平台，其架构优化实践对同类大规模并发访问的网上交易系统具有重要的借鉴意义。