李 杨，李 雯，胡志鹏，戴琳琳

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

经过多年的发展，中国铁路客票发售和预订系统（简称：客票系统）已成为覆盖全国的超大型分布式售票网络[1]；12306 互联网售票系统是其中一个最主要的售票渠道，自上线以来，以便捷性迅速得到广泛认可[2]，越来越多的旅客通过互联网购票，互联网售票量呈大幅增长态势，售票高峰期的大量并发请求给互联网售票系统带来的压力也屡创新高。

余票查询是12306 互联网售票系统的功能之一，也是旅客购票时关注的焦点。为了提升查询效率和并发性能，更好地保证12306 互联网售票系统的稳定性和高效性，结合分布式内存数据库[3]，采用多级缓存、数据同步等多种技术手段，大幅提升了余票查询业务的处理性能，成功经受2015 年以来历次春运售票高峰的考验。

在旅客购票过程中，偶尔会出现余票数据不一致问题：旅客能够在12306 网站或者12306App 上查询到余票，下单时却被提示余票不足，导致出票失败，降低了旅客的购票体验，甚至招致旅客投诉。为此，对余票查询业务的数据处理流程进行梳理，查明余票数据不一致的原因，并提出余票数据一致性保障技术方案，有效减少余票数据不一致的问题，让旅客在线购票时获得更佳的用户体验和更高的满意度[4]，降低旅客投诉率。

1 余票查询业务数据处理的总体流程

总体上，12306 互联网售票系统余票查询业务的数据处理流程需要跨越4 个网络区域：客票网、客服内网、客服外网和互联网，如图1 所示。

1.1 客票网

客票网区域的数据处理主要负责余票数据的产生和数据同步：（1）从铁路局集团公司数据中心席位库抽取余票原始数据（也称为余票基础数据），将其存储到铁路局集团公司余票库；（2）将各铁路局集团公司余票库中的余票基础数据同步到中国国家铁路集团有限公司（简称：国铁集团）数据中心，以完成全路余票基础数据汇总。

1.2 客服内网

客服内网区域的数据处理主要负责余票计算。在12306 互联网售票系统中，旅客通过12306 网站或者12306App 查询到的余票结果是客服内网区域中余票计算缓存集群基于余票基础数据和各种计算规则生成的计算结果，涉及较为复杂的余票业务逻辑。

1.3 客服外网及互联网

客服外网和互联网区域的数据处理主要负责提供余票查询服务，12306 互联网售票系统在用户终端与内存集群的实时查询结果之间设置有2 级缓存：设置在客服外网区域的余票结果缓存和设置在互联网区域的内容分发网络（CDN，Content Delivery Network）缓存，以缓解大量余票查询请求对网站服务器的压力。

2 余票查询业务处理的主要流程

2.1 余票基础数据生成与同步

目前，铁路客票系统使用的数据复制系统覆盖范围广、效率高，是国内应用非常成功的复制系统[5]。其中，余票基础数据同步更为复杂，通过组合运用多种同步产品，实现余票数据在异构数据库之间的高速数据同步[6]。余票数据的生成与同步以分布在18 个铁路局集团公司的数十个席位库为数据源，其主要流程如下：

（1）进行客票交易时，由铁路局集团公司席位中心完成席位处理，之后通过席位信息计算得到余票基础数据，将其存储在铁路局集团公司余票库；

（2）通过数据库复制，将本铁路局集团公司多个席位中心的余票基础数据实时汇总至铁路局集团公司余票库；

（3）汇总后的铁路局集团公司余票基础数据通过复制，实时同步到国铁集团双活数据中心的基础数据节点及余票前置数据库中，完成18 个铁路局集团公司余票基础数据汇总。

（4）国铁集团双活数据中心的余票前置数据库通过实时数据同步，将余票基础数据同步到双活数据中心余票计算缓存集群。

2.2 余票结果计算

余票业务计算逻辑非常复杂，不仅数据处理量大（余票基础数据的数据量高达数千万行），同时依据各种售票规则完成余票结果计算，余票查询时余票结果计算逻辑的流程如图2 所示。

如图2 所示，每次余票查询都要在余票原始数据的基础上，经判断车次开行规律、判断预售期、处理调度命令、处理席位共用定义等多步计算[7]，最后生成余票查询结果。

图2 余票结果计算流程

2.3 余票数据查询

余票查询过程涉及内存计算查询集群和二级余票查询结果缓存。

当余票查询时，余票计算缓存集群经过复杂计算之后，得到余票查询结果，在返回余票查询结果过程中，余票查询结果依次缓存在客服外网内的余票结果缓存集群和CDN 缓存中，并设置一定的缓存有效期；在缓存有效期内，前台应用再次查询余票时，是直接从缓存集群中读取余票查询结果。

3 故障分析

余票问题存在多种现象，如：旅客从多个渠道（车站大屏、12306App、12306 网站）看到的余票数量不一致；旅客在12306 网站上看到有余票，但下订单时却被提示余票不足；实际余票充足，但旅客却无法查询到余票等等。

根据系统运维经验，余票问题的主要原因是余票查询业务处理的3 个主要流程出现故障，即余票基础数据生成与同步故障、余票结果计算故障和余票数据查询故障；此外，还会出现与业务处理流程无关的系统故障，包括硬件、服务器、系统进程等故障。

3.1 系统故障

系统故障主要包括系统硬件故障和系统软件故障。系统硬件故障是指服务器硬件、网卡、交换机等承载余票业务的硬件基础设施出现故障。系统软件故障是指查询路径上的缓存或余票计算集群出现故障、数据库同步路径上的同步程序出现故障（包括数据同步产品挂起、数据传输僵死等）。尽管客票系统的硬件设备和系统软件都采用冗余配置实现高可用[8-9]，以避免单节点故障，但故障切换期间或多节点故障时难免会对余票查询业务造成一定影响。

3.2 余票基础数据同步故障

余票基础数据同步故障，是指在数据同步过程中数据变动监听、数据变动采集、数据传输、数据载入时出现延迟或者业务失败、甚至数据丢失的情况，从而造成数据同步链路上任意2 个节点之间的数据不一致，进而影响余票查询业务的完整性。

3.3 余票结果计算故障

余票结果计算故障，主要是因为在批量调整车次时，由于车次变动较多，偶尔会导致席位共用策略未及时生成；或者是临时增减停靠站时，计划管理后台进程未及时检测到停靠站变化，致使席位共用策略生成延迟，进而导致余票结果计算不准确，余票查询不到、发售不出。

3.4 余票查询缓存问题

余票查询业务采用2 级缓存来降低服务器压力，平衡用户的购票需求和网站服务器的压力。余票计算结果缓存时效设置的长短及数据更新频率会直接影响余票查询时的数据一致性，如余票计算结果缓存的有效期设置为5 min，在这5 min 内若有购票操作完成，则再次进行余票查询时，就会出现余票查询结果与实际余票数量不一致的问题。

4 余票数据一致性保障技术方案

针对上述4 类故障，采用多种方案相结合，来保障余票查询功能的数据一致性，如表1 所示。

表1 余票查询数据一致性保障方案

4.1 加强数据同步链路监控

通过余票数据同步全链路监控系统能够对数据同步过程中的数据节点健康状况以及数据同步情况进行实时监控，也能对余票查询路径上的缓存和内存数据库健康状况进行监控。

如图3 所示，余票数据同步链路监控画面可展示余票数据生成和同步的总体流程、流向和途径节点，包括从铁路局集团公司数据中心余票库到国铁集团双活数据中心余票前置数据库进行余票汇总，从余票前置数据库经异构数据同步（包括数据采集、数据传输、数据载入多个环节）到多个余票计算缓存集群，通过代理、被动检测以及主动获取等多种不同监控数据获取方式[10]，对链路上关键节点的硬件设备和系统软件进行监控，包括服务器、内存、CPU、网络、同步产品进程、数据库以及缓存集群状态等情况，并在节点发生故障时及时发出告警。

图3 余票数据同步全链路监控画面

4.2 余票数据一致性检测与修复

余票数据变动非常频繁，时效要求高。考虑到票额充足时，旅客对余票数据一致性要求相对不高，但票额不足时对余票数据一致性要求十分强烈的特点，余票数据一致性检测与修复采取多种保障机制，重点检测余票不足车次的余票数据一致性，并进行数据修复。

（1）定时根据候补兑现请求获取待检测的车次列表，根据始发车次、发站、到站、始发日期、席别，分别调用余票接口和查询席位库获取余票数据，对比两者结果；若余票数据一致，表示余票查询通过数据一致性校验；若不一致，则触发数据同步，将该车次的余票数据从源中心的席位库重新同步，等待下一次候补兑现请求的轮询检测。

（2）监控候补兑现结果，若候补余票计算出存在符合条件的余票时，候补服务会进行候补需求兑现，调用扣票程序，当扣票程序返回的错误提示为“没有足够的车票”时，将触发余票检测程序，对比余票查询接口返回结果和席位库查询结果，若两者一致时，表示余票数据通过一致性校验，需要将失败请求通过告警通知发出，进行人工处理；若两者不一致时，则触发数据同步，将对应车次的余票基础数据从源中心的席位库重新同步，等待下一次候补请求的轮询检测。

（3）利用交易中间件，通过日志监测“没有足够的车票”报错信息，获取报错车次，之后通过工作流轮询表，按车次检测余票查询接口查询结果与票源中心余票数据的一致性，若发现数据不一致，则从席位库重新生成余票基础数据，并完成余票基础数据同步。

4.3 余票计算规则检查

为确保席位共用策略中设置的席位共用关系与停靠站的站序匹配，通过工作流轮循或手工方式执行检查，检查方式如下：

（1）进行停靠站维护时，在国铁集团基础数据中心由数据维护程序记录对应车次的维护日志。工作流根据日志轮循生成席位共用策略，同时控制数据处理数量，保障复制系统工作稳定；

（2）工作流定期检查预售期内车次对应的席位共用策略是否缺失，若发现席位共用策略缺失，则重新生产该车次的全程席位共用策略；

（3）为铁路局客票管理人员提供前台工具，由操作员手工执行立即检查，并生成席位共用策略，以避免轮循速度较慢、等待发售席位共用的票额时，出现席位共用策略未及时生成的问题。

4.4 余票数据缓存有效期动态调整

强化清理缓存机制，动态设置车次的余票查询结果的缓存有效期，即余票计算结果在CDN 以及余票结果缓存集群中不再按固定的有效期进行缓存，而是根据不同车次动态设置余票查询结果的缓存有效期。例如，对于热点车次或是距开车时间较近的车次，其余票查询结果的数据缓存有效期可设置得较短，确保能够及时刷新余票结果数据。对于冷门车次或停运车次，余票查询结果的缓存时间会调整得略长一些，以减少因余票查询结果缓存造成的余票查询数据不一致。

5 实施效果分析

为了准确分析余票数据一致性保障技术方案的实施效果，以铁路客户服务中心信息系统提供的旅客对于“查询到余票后，提交订单时又提示余票不足”问题的投诉量作为评价指标，对2018 年8 月—2020 年10 月的投诉量进行统计，如图4 所示。

图4 旅客针对余票问题的投诉量统计（2018.8—2020.10）

由图4 可以看出：12306 互联网售票系统于2019 年12 月底实施余票数据一致性保障技术方案之后，旅客投诉量开始明显降低；旅客投诉量随时间略有高低起伏，在五一、十一、春运售票高峰期均出现投诉量增多。

鉴于不同时段旅客的购票需求存在差异，售票量会影响旅客投诉数量。为了更好地进行分析，生成2018 年8 月—2020 年10 月的12306 互联网售票量指标统计图，如图5 所示。

由图5 可知，售票量随时间波动，节假日期间会出现波峰，2020 年初因疫情原因，售票量还出现了一个比较显著的低谷，直至2020 年7 月，售票量才基本恢复正常。

结合投诉量C和售票量T，定义投诉比指标R=C/T，生成2018 年8 月—2020 年10 月旅客针对余票问题的投诉比统计，如图6 所示。

图5 12 306 互联网售票量统计（2018.8—2020.10）

图6 旅客针对余票问题的投诉比统计（2018.8—2020.10）

由图6 可知，往年售票高峰期的投诉比基本在一个水平线上，2019 年12 月底实施余票数据一致性保障技术方案之后，投诉比一直处于一个较低的水平；因疫情原因，2020 年初投诉比较低，2020 年7月售票量恢复正常之后，投诉比也没有明显增多；尤其在十一期间，因国外疫情汹涌，旅客主要选择国内出行，铁路动车客运发送量再创新高，而此期间旅客因余票问题投诉仅有1 条，投诉率降低了80%以上，余票一致性保障技术方案的应用效果非常显著。

6 结束语

自12306 互联网售票系统上线以来，余票查询一直是一项重点业务，也是旅客关注的焦点。12306互联网售票系统采用分布式内存余票计算集群、数据同步、多级缓存等多种技术，大幅提高了余票查询业务的处理性能，较好地适应了互联网售票量急速增长的形势。但是，由于余票查询业务的处理流程、计算逻辑和同步机制都较为复杂，偶尔会出现余票问题，影响了旅客购票体验。

通过细致梳理余票查询业务的数据处理流程，分析造成余票问题的各类原因，针对这些故障原因，提出余票数据一致性保障技术方案，并于2019 年12月底实施。根据2018 年8 月—2020 年10 月12306互联网售票系统相关数据的统计，该方案可显著提高余票查询数据一致性，大幅降低因余票问题导致的旅客投诉率，应用效果显著。