APP下载

12306互联网售票系统的架构优化及演进

2015-06-28朱建生王明哲杨立鹏阎志远张志强

铁路计算机应用 2015年11期
关键词:车票订单架构

朱建生,王明哲,杨立鹏,阎志远,张志强

(中国铁道科学研究院 电子计算技术研究所,北京 100081)

12306互联网售票系统的架构优化及演进

朱建生,王明哲,杨立鹏,阎志远,张志强

(中国铁道科学研究院 电子计算技术研究所,北京 100081)

12306互联网售票系统是中国铁路最重要的售票渠道。本文介绍系统的体系架构及其在上线初期遇到的性能问题,以及为解决相关问题,改善用户体验进行的几次重大架构优化的思路和实践,同时简要介绍12306在架构优化方面下一步的工作设想。

12306;互联网;售票;架构

12306 互联网售票系统是基于中国铁路客票发售和预订系统(简称:客票系统)这一核心系统构建的。2011年6月12日,系统投入试运行,发售京津城际列车车票;2011年9月30日,发售全路动车组车票;2011年底,发售全路列车车票,互联网正式成为铁路新的售票渠道。

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

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

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

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

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

2012年春运期间,持续的高并发访问使系统在多个方面出现性能瓶颈,如图2所示。

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

出现的主要问题包括:

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

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

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

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

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

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

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

2 系统架构的调整及优化

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

(1)使用内存计算NoSQL数据库取代传统数据库,大幅提升车票并发查询能力,车票查询的TPS/ QPS(Transaction/Query per Second)由不足1 000次/s提升至超过20 000次/s,RT(Response Time)由原来的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平台全面替代了原有的小型机平台,其架构优化实践对同类大规模并发访问的网上交易系统具有重要的借鉴意义。下一步我们将继续优化订单/电子客票双活架构、系统故障感应、隔离以及智能切换技术,同时深入开展网站用户行为分析和安全管控机制建设,持续提高系统的安全性、可靠性及稳定性,改善用户购票体验。

[1]陈 皓.由12306.cn谈谈网站性能技术[EB/OL]. http:// coolshell.cn/articles/6470.html.

[2]幽云十八.透过12306五大焦点看高性能高并发系统[EB/ OL]. http://storage.it168.com/a2012/0217/1313/000001313424. shtml.

[3]王明哲,张振利,徐 彦,等. 铁路互联网售票系统的研究与实现[J]. 铁路计算机应用,2012,21(4).

[4]赵 光. 铁路互联网售票系统网站建设的优化探讨[J]. 上海铁道科技,2012(3).

责任编辑 王 浩

Architecture optimization and evolution of 12306 Internet Ticketing and Reservation System

ZHU Jiansheng, WANG Mingzhe, YANG Lipeng, YAN Zhiyuan, ZHANG Zhiqiang
( Institute of Computing Technologies, China Academy of Railway Sciences, Beijing 100081, China )

12306 Internet Ticketing and Reservation System was the most important ticketing channel for Chinese railway. This paper introduced the system architecture and its performance problems in the beginning, as well as several major architecture optimization ideas and practices to solve the relevant problems, improve the user experience, and brief l y introduced the idea of the architecture optimization of the next step.

12306 Website; Internet; ticketing; architecture

U293.22∶TP39

A

1005-8451(2015)11-0001-05

2015-08-02

中国铁路总公司科技研究开发计划重大课题(2013X009-A-1),(2013X009-A-2)。

朱建生,研究员;王明哲,副研究员。

猜你喜欢

车票订单架构
基于FPGA的RNN硬件加速架构
春节期间“订单蔬菜”走俏
订单农业打开广阔市场
功能架构在电子电气架构开发中的应用和实践
找车票
基于云服务的图书馆IT架构
“最确切”的幸福观感——我们的致富订单
WebGIS架构下的地理信息系统构建研究
我是个“小车票迷”
怎样做到日订单10万?