铁路客票系统响应式流量控制策略研究

李贝贝，朱建生，阎志远，朱建军，戴琳琳

（1.中国铁道科学研究院 研究生部，北京 100081；2.中国铁道科学研究院集团有限公司 电子计算技术研究所，北京 100081)

2012年春运期间，12306互联网售票网站上线，支持全路列车车票发售，自此，火车票不仅可以通过电话订票、车站与代售点窗口等方式进行购买，还可以通过12306网站进行购票。随着12306网站的推广应用，铁路互联网售票量在各售票渠道中的占比逐步达到80%以上，已经成为旅客最主要的购票方式。2020年春运期间，12306网站在售票高峰日的网络点击量达到1 495亿次，意味着每秒接受170多万的访问量，而巨大的访问量并非全部来源于旅客点击，更多的访问量来源于抢票软件的自动提交。因此，以面向铁路旅客售票为基础的铁路客票系统的建设，不仅需要满足旅客的基本购票需要，还面临着第三方抢票软件带来的高并发运行压力。近年来，随着响应式理念在网页设计[1]、网络路由[2]、公交调度[3-4]、汽车交互设计等方面的设计与应用[5]，基于响应式理念探索改造铁路客票系统业务，建立客票系统后端资源组织决策模式，进而控制铁路客票系统的业务流量等，成为旅客购票环境公平性、内部资源集约性、业务流量均衡性的关键。

1 铁路客票系统业务模式

1.1 总体架构

铁路客票系统目前采用集中+分布式的体系架构，铁路客票系统由中国国家铁路集团有限公司(以下简称“国铁集团”)、铁路局集团公司和车站三级组成，其中互联网售票与手机售票等业务集中部署在国铁集团，全路客票席位及验检票业务等部署于18个铁路局集团公司，车站级一般部署终端设备与轻业务。铁路客票系统总体架构如图1所示。

图1 铁路客票系统总体架构Fig.1 Overall architecture of railway ticketing system

国铁集团级客票系统，已建成同城客票第一生产中心和第二生产中心，采用双中心双活的系统架构，保障客票系统在国铁集团级的高可用性。同时为保障铁路客票系统的安全，内部采用三级网络架构，包括客服外网、客服内网和客票网[6]，各层级网络的边界均设有安全防护措施。在业务实现上，内容分发网络(Content Delivery Network，CDN)与源站联动，实现各专线接入时的流量配比；客服外网层主要通过负载均衡和网站应用级入侵防御系统(Web Application Firewall，WAF)拦截大部分的攻击流量，作为各应用服务的入口，实现基本的交易排队、余票缓存、验证码、监控、消息通知等相关服务；客服内网层实现基本的用户登陆、常用联系人查询、接续换乘及候补兑现等服务；客票网作为铁路客票系统的核心交易层，不仅支持高并发业务查询(订单查询、实名制查询、历史订单查询)等，还提供客票席位计算、余票计算、各铁路局集团公司中心席位的中间件路由与寻址，以及客票基础数据与电子票库等的存储等。国铁集团二中心同时支持电话订票、营销分析与常旅客等服务。

铁路局集团公司级客票系统部署在18个铁路局集团公司的中心机房，具备席位管理、自动售票、自助验票检票、收入统计和铁路局集团公司级营销分析等系统功能；铁路局集团公司按照售票高峰量、售票情况配置硬件资源，席位数据库主要采用Sybase ASE SQL Server+小型机的部署方式，数据存储资源以集中式共享存储为主；18个铁路局集团公司的数据库节点共计200多个，存储数据除了席位、交易存根等信息外，还包括线上和其他铁路局集团公司售出该局票后，回传到铁路局集团公司的存根、电子票等数据。铁路局集团公司级的其他硬件资源还包括验票检票、交易中间件、数据传输等应用服务器。

车站级客票系统主要部署在作业终端，包括窗口售票、窗口退票、自助验票检票、自动售取票等终端设备，窗口终端大多部署客票专用应用软件，采用C/S架构访问后台服务。目前大部分车站已取消车站级数据库服务器；少数车站仍然存在数据库服务器存储交易数据，交易信息需要上传至铁路局集团公司中心数据库和其他席位归属中心数据库中。

1.2 高并发业务数据组织方式

2021年春运期间，铁路客票系统日高峰访问量超过2 000亿次，其中多集中在余票查询、订单查询及实名制查询上。

（1）余票查询。全路席位及余票信息分布于各铁路局集团公司客票网，每个铁路局集团公司的席位数据以多节点方式存储。当席位数据发生变化时，余票信息需要实时计算与更新，随着电子客票、全路通退与通改签、线上线下预售期统一等业务的不断发展，余票查询的业务组织方式逐渐转变为铁路全渠道都可以查询全国范围预售期内的余票信息。余票信息被计算后，将通过数据库复制技术，同步到国铁集团级的线下余票集群和线上余票集群，再将余票数据缓存到客服外网的余票缓存数据库或者公有云。线下业务查询余票数据时，在线下余票集群进行查询；互联网查询余票时，可以根据并发情况，在余票缓存集群或公有云上查询余票信息。余票数据组织如图2所示。

图2 余票数据组织Fig.2 Organization of remaining tickets

（2）实名制与订单查询。随着电子客票在各高速铁路、普速铁路的推广与应用，客票实名制信息与订单信息已实现国铁集团级的集中存储，实名制与订单数据组织如图3所示。线上、线下业务产生的实名制信息与订单信息，分别记录到一中心和二中心的A层电子票库，通过数据库复制技术，再将A层数据同步到T层电子票库。一般A层电子票库主要实现售票交易，T层电子票库主要实现退票、改签等交易。A层与T层数据，通过数据库复制技术，分别被最终同步到客服内网的实名制集群与订单集群。

图3 实名制与订单数据组织Fig.3 Organization of the real-name system and order data

1.3 流量控制机制

（1）CDN与源站联动。CDN为互联网请求的流量配比中心，可以接受来自不同通信运营区域的客户IP业务请求，并设置不同的专线配比转发给服务端。客户端流量调度模块可以解析不同区域的客户请求，当某区域节点宕机时，客户端流量调度模块能够计算配比并更改配比设置。服务端流量调度模块可以监测客户端流量变化，根据流量的变化优化调整CDN流量配比，最大化利用专线带宽。

（2）WAF数据风控。WAF数据风控多以重复IP提交、账户风险等级等多种方式，拦截大部分的高并发作弊请求，在订单查询、支付等环节，减少撞库、黄牛倒卖、网页篡改、DDoS攻击、账号泄露、木马植入等风险，以数据安全为核心，减少无效流量入侵铁路客票系统。

（3）负载均衡。铁路客票系统内部的多个子业务系统，多采用分布式、高可用架构进行部署，多应用实例之间一般通过软负载或硬负载实现服务的反向代理，负载均衡模块可以实现业务流量调度，其中流量调度多采用加权轮询或加权最小连接调度等算法实现。

（4）线上与线下业务流量分离。铁路客票系统余票信息通过复制与缓存等技术，在国铁集团级实现面向线上与线下不同业务应用的余票集群，使得不同业务交易在余票信息的使用上加以区分，独立线下与线上的业务流量。

（5）数据库承载核心业务流量。无论是A层还是T层的电子票库节点，部分业务逻辑的实现，均通过数据库存储过程完成，减少数据库的外部访问流量，提升数据访问性能，但增加了业务与数据之间的高耦合度。

2 铁路客票系统响应式 流量控制设计

响应式方法能够结合不同的业务，为用户提供更加便捷、灵活的用户体验。为实现响应式流量控制，铁路客票系统通过业务模式的更新与改造，建立后台资源组织决策模式，基于服务端的能力输出方式，在准实时业务、预约性业务及交易类业务等环节进行设计与优化，在满足线上与线下不同用户的购票需求的同时，实现对铁路客票系统的业务流量控制。

2.1 响应式流量控制策略应用架构设计

铁路客票系统响应式流量控制采用集中式架构，主要应用于国铁集团级，内部分别部署于客服外网、客服内网和客票网。为保证系统安全可靠运行，在国铁集团级客票系统中，严格进行分区分域管理。铁路客票系统响应式流量控制应用架构如图4所示。

图4 铁路客票系统响应式流量控制应用架构Fig.4 Application architecture of responsive traffic control in the railway ticketing system

铁路客票系统响应式流量控制功能，主要基于铁路客票系统的准实时响应式、预约性响应式及交易类响应式等相关业务服务进行设计。

（1）准实时响应式。准实时响应式主要面向预售期内余票量不足或者没有余票时而进行的设计，在客票系统内部，客服外网提供候补入口及候补排队功能，客服内网通过余票计算集群，对客票网内各铁路局集团公司的票库进行实时监控并完成扣票动作，实现候补订单的兑现，并记录候补订单，完成候补订单对旅客的通知功能。准实时响应式的构建，可以减少高频的订单查询流量、余票查询流量等。

（2）预约性响应式。针对预售期外的旅客购票需求，客服外网提供预约购票入口、预约排队及通知等服务，客服内网提供预约单需求分析、预约订单计算、预约兑现等功能，客票网提供预约购票规则管理等功能，实现与铁路列车调度图等的联动与分析。预约性响应式的设计，可以为高峰期的购票提前分担流量，使购票的流量在空间分布上更加均衡。

（3）交易类响应式。交易类响应式主要由统一接入平台、预售期统一和电子客票集群改造3部分构成，主要分布于客票网内，部分分布于客服内外网，如统一接入服务等。统一接入服务在各级网络中均存在，主要分为客服外网统一接入平台、客服内网统一接入平台、客票网统一接入平台。预售期统一将线上互联网、手机客户端等与线下窗口、代售点等的客票销售预售期保持一致，避免线下预售期提前带来的可能囤票操作，分流部分线下售票流量。电子客票集群改造主要将既有Sybase数据库中的存储过程逻辑外移，并适配PostgreSQL数据库，通过工作流服务与微服务方式进行改造，均衡内部业务流量。

2.2 响应式流量控制业务设计

2.2.1 候补购票

候补购票的流量控制主要通过业务层进行控制，当用户提交候补订单后，候补订单进入排队队列，此时用户再查询相应车次余票信息时，无需再通过客服外网至客服内网再至客票网层级的较长业务逻辑链，而是通过缓存存储的车次余票信息快速响应，因而可以极大程度减少12306用户对余票查询业务请求量。候补购票业务流程如图5所示。

图5 候补购票业务流程Fig.5 Business process of alternative tickets

当用户完成候补订单支付时，候补订单数据库及候补队列系统中均有记录，至此一个候补订单生成。通过轮询余票查询，获取返回的余票实现候补兑现。候补兑现所需要的所有信息查询与调用，均在候补订单数据库中进行，候补订单数据库能够保证数据存储的安全与准确。

2.2.2 预约购票

预约购票的业务流程，主要包含用户预约需求汇总、运行图判定及需求兑现3个流程，预约购票业务流程如图6所示。预约购票实现过程中如下：①用户提交模糊的预约需求单(包含乘车日期、上车站、下车站、席别、发时区间、到时区间、历时等)；②系统根据“乘车日期+区间+席别”汇总，划分成不同的需求队列；③车次运行图确定后，触发系统工作流，先为用户的预约需求生成系统推荐的匹配车次(如Top10)，然后通知引导用户自行选择相匹配的车次；④在列车预售期开始的前1 d，系统集中兑现用户预约需求；⑤兑现成功后，系统通知用户及时支付、完成订单；⑥兑现失败的，判断用户是否接受转为候补订单，对于未接受的，终止业务流程；对于已接受转候补订单的，系统自动为用户转为候补订单。

图6 预约购票业务流程Fig.6 Business process of booking tickets

2.2.3 交易过程优化

铁路客票系统交易过程优化的过程，主要将数据库存储过程中的业务逻辑与数据库进行解耦，将沉淀在Sybase数据库存储过程中的业务逻辑进行抽离，利用业内主流平台框架模型和语言重新实现。交易过程优化的响应式改造，主要包括客票全渠道预售期统一、统一接入平台和交易业务服务化的设计等。交易过程优化业务功能如图7所示。

图7 交易过程优化业务功能Fig.7 Business function on optimization of the transaction process

（1）全渠道预售期统一。改造线下程序，主要包括窗口程序(包括车站窗口、代售点等)，自动售票(包括自动售票机、验检票等)程序与票务管理(包括票务计划、票价等)，实现相关扣票命令指向国铁集团终端服务，完成线下余票集群对统一预售功能的支持，并实现线下业务行为分析与请求排队，同时完善交易中间件导航各类服务集群。

（2）统一接入平台。部署于国铁集团级，以面向业务服务为主，主要包括支持多种协议接入、结合客票应用的安全风险控制、业务访问的鉴权认证、业务访问的导航管控及管理等5个方面，其中管理功能实现对接入请求和连接的管理，包括请求超限时的熔断和限流、接口管理、流量监控、流量分析等。

（3）交易业务服务化。针对既有铁路电子票库，抽离Sybase数据库中的存储过程逻辑，通过微服务方式进行改造，从业务角度进行服务拆分，抽离出接入层、编排层、基础服务、业务服务和数据服务等，降低应用模块的耦合性，进一步提升交易类响应式的流量调度和微服务治理，实现数据的统一访问控制和权限管理。

3 铁路客票系统业务响应式流量控制改造效果

铁路客票系统业务响应式流量控制的研究，为铁路旅客运输带来极大的便利。目前，以候补购票为代表的准实时响应式已全路上线；以预约购票为代表的预约性响应式处于研发过程中；新建的交易类响应式已经部分上线，并逐步扩大应用范围。

3.1 准实时响应式

铁路客票系统的预售期天数不固定，但目前为30 d，预售期内的车票存在有票和无票2种情况。有票情况下，旅客无论从线上网站、12306客户端等，还是从线下代售点、车站窗口等途径购票时，均可以实时满足需求；无票情况下，候补购票的应用与全面推广[7]，准实时地解决旅客需要不断关注余票变化的问题，降低用户时间成本，提升用户体验。

2019年5月22日起，铁路候补购票服务已扩大应用到所有旅客列车。候补购票为旅客提供了更加方便快捷的购票服务，同时有利于客运组织管理者及时掌握旅客出行需求，科学组织列车开行，让运力安排更加精准、旅客购票体验更佳[8]。

候补购票服务的推出，一定程度上也可以提升用户信息安全，降低用户使用第三方抢票软件而导致的用户隐私信息泄露的风险，减少旅客购票过程中额外经济支出的问题。同时，第三方抢票软件的请求量的降低，可以减少对客票系统的无效请求，降低铁路客票系统的外部访问流量，将预售期内无余票情况下的旅客购票流量，最大程度地约束在铁路客票系统内部进行均衡，提升铁路客票系统的鲁棒性。

3.2 预约性响应式

既有铁路客票系统中，30 d预售期以外未到起售时间时，旅客如果有购票需求，仍然需要等到预售期30 d当日的指定起售时间再进行购买，使用上仍然不便利。

在结合计划管理、票额预分、预约业务规则制定等售票组织策略的基础上，考虑预约购票服务，淡化车票预售期，事先了解旅客的出行需求，按照出行需求的时间、出发到达城市、数量等信息，安排并优化开行方案、席位复用、席位共用、票额预分等售票组织策略，促进“一日一图”策略的实现，实现铁路运力资源的最大集约化利用，提升用户出行效率和出行体验。一旦进入铁路规定的预售期，预约购票服务自动终止[9]。预约购票一定程度上可以减少新票发售时的抢票现象，缓解系统和网络压力，同时可以减少余票查询消耗的大量资源，在进一步提升旅客购票体验的同时，平衡高峰期的客票系统网络流量。

3.3 交易类响应式

（1）全渠道预售期统一。既有电话订票、互联网、手机客户端等线上售票渠道预售期为30 d，车站窗口、自动售票机、代售点等线下销售渠道的预售期为28 d，该举措的目标为引导旅客优先线上购票，针对遏止线下囤票、倒票等问题起到明显作用，但未能满足不同旅客的购票需求。全渠道的预售期统一，可以分担部分互联网售票的业务流量并引导至线下，一定程度上控制业务流量的均衡性。2020年11月，全渠道预售期统一上线运行。全渠道预售期的统一，控制线下售票的高频异常，实现线上、线下购票速度的协调调度，实现对席位库的有序安全访问。功能上满足交易逻辑控制、线下余票查询、线下业务行为分析和线下排队系统等4部分，有序地确保客票系统核心交易的平稳、安全和高效运行。

（2）交易业务服务化。铁路客票系统内部的售票业务逻辑组织，一般通过访问中间件，实现各铁路局集团公司中心的席位操作。内部业务实现以Sybase数据库的存储过程为主，与数据库本身绑定紧密。将数据库中的业务逻辑通过拆分并以微服务方式重新实现，可以满足分布式、高可用等特点，实现业务流量的均衡性。交易业务微服务化改造，实现客票系统业务与数据存储松耦合，促进客票系统架构转型，实现业务分布式扩展和云化能力。目前新增电子票库微服务化集群节点，支撑80万用户线上购票、支付、乘意险、候补购票等业务，每天支撑售票1.1万张、候补购票150张。与此同时，交易业务服务化将业务流量从数据库中进行分离，提供集成化、标准化的技术组件能力，实现应用从开发、编译、部署、测试、发布到运行的全生命周期的自动管理和标准发布流程管理，支撑系统7×24 h不间断服务和自动化运维，降低系统运维成本，并支撑业务快速迭代，降低开发周期，为业务应用的持续创新和稳定运行提供有力保障。

4 结束语

我国铁路客票系统经过20多年的发展，目前已成为世界上规模最大的实时交易系统之一，面对每日如此巨大的请求量，确保各业务系统模块的健壮，有助于保障系统的稳定、持续运行。研究从响应式流量控制的角度，设计优化铁路客票系统，推动铁路客票系统内部应用各模块的业务流量更加趋向均衡。但是，铁路客票系统业务功能丰富、系统架构复杂，可以进行流量控制与均衡的关键点较多，仅从响应式理念的角度进行分析还不够，还需要进一步扩大研究范围，从系统架构、业务功能及安全防御等多个角度广泛优化铁路客票系统的流量控制机制。