铁路车站余票查询服务系统设计与实现

2021-06-04王思宇梅巧玲梁晓慷

铁路计算机应用 2021年5期

王思宇，梅巧玲，马杰，梁晓慷

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

中国铁路客票发售与预订系统（简称：客票系统）按“中国国家铁路集团有限公司（简称：国铁集团）—铁路局集团公司—站段”三级架构建设，由国铁集团双活数据中心、18个铁路局集团公司地区中心及2 000多个车站系统构成，客票系统部署范围覆盖全国铁路所有客运车站。长期以来，铁路车站余票查询服务由各铁路局集团公司地区中心的查询中心承担，由于查询中心不同，服务器性能存在差异，数据读写未分离，尤其在高峰期，查询能力不足，查询响应慢，导致车站售票窗口、自动售票机及车站大屏余票查询显示不及时，引起旅客误解，并且，查询中心仅能获取本地区中心管理车次的余票信息[1-2]。

为此，本文依托客票系统，设计铁路车站余票查询服务系统，遵循高可靠性、高可用性及可扩展性设计原则，采用快速查询、分布式缓存、分布式内存数据库、多维度故障检测等技术，实现全国铁路余票信息共享，支持线下的车站大屏余票查询、自助售票机余票查询、车站售票窗口余票查询及线下其他应用的余票查询，从而提升车站余票查询服务质量。

1 系统设计

1.1 系统架构

车站余票查询服务系统的设计依托客票系统，由前置微服务、缓存集群、内存集群、数据同步及配置管理中心组成，为双中心双活架构，如图1所示。系统以超文本传输协议（HTTP）的方式对内提供服务。

图1 车站余票查询服务系统架构

（1）前置微服务

前置微服务是车站余票查询服务系统接入网关，使用微服务框架开发，以HTTP的方式提供服务接口，利用负载均衡技术保证接入网关的可扩展性与高可靠性，提供车站余票查询服务[3]。

（2）缓存集群

缓存集群是基于键值对的非关系型数据库，支持数据写入、删除、定时自动删除等数据操作类型。缓存集群支持从配置管理中心读取数据，自动删除配置时间。该操作可以用于短时间内相同请求参数的快速响应，减少内存集群计算余票的压力[4]。

（3）内存集群

内存集群为分布式内存数据库集群，存储余票计算相关数据。通过请求调用，在原始余票信息基础上经过查询条件预处理、预售期判断、调度命令处理、共用及复用计算等多步骤的数据加工，计算出余票结果[5]。

（4）数据同步

通过客票系统的数据库复制系统，将基础数据、余票数据复制到客票系统中间件系统，利用消息中间件技术，将数据发送到开源消息队列中间件上，通过数据消费解析服务，将数据实时写入内存集群，完成客票核心数据库数据与内存集群的数据实时同步[6-7]。

（5）配置管理中心

配置管理中心能够集中化管理和应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具有规范的权限和流程治理功能。支持灰度发布、权限管理、发布审核及操作审计。

1.2 系统功能模块

车站余票查询服务系统的主要功能模块包括接入服务、故障集群检测及流量调度、风险防控、数据缓存、余票计算等。系统各功能模块间的工作流程，如图2所示。

图2 功能模块间的工作流程

（1）接入服务模块

接入服务模块支持各种业务的接入服务，提供多元化定制接口功能，支持程序快速迭代升级。目前，提供车站售票窗口、自动售票机、电话订票、车站大屏余票等业务接入服务。

（2）故障集群检测及流量调度模块

故障集群检测及流量调度模块，根据内存集群健康指标，建立多维度内存集群健康检测模型，自动检测集群健康状态，当发现某个内存集群不健康时，接入服务模块自动修改故障内存集群的流量配置，隔离故障集群，避免影响系统服务。

（3）风险防控模块

风险防控模块提供异常请求的卡控功能，支持自定义风险卡控规则，包括对接口、请求节点、请求频次多个维度的卡控规则设置。利用缓存服务，将请求信息保存到缓存中，通过读取卡控规则，卡控高频节点的访问请求[8]。

（4）数据缓存模块

数据缓存模块是根据不同接口的查询量或业务需求进行缓存规则的设置，支持单个接口自定义设置缓存规则。缓存可以减少短时间内相同请求的余票计算次数，减小内存集群的访问压力，提高系统的稳定性。

（5）余票计算模块

余票计算模块支持多维度的余票计算，例如：以发站、到站、乘车日期查询余票结果，查询指定日期范围内的途径此车站的余票结果，查询指定车次所有发到站的余票结果等。

2 关键技术

2.1 快速查询

车站余票查询服务系统基于微服务框架开发，部署一组小型服务，小型服务组内的各服务之间在结构上松耦合，采用轻量级通信机制，实现缓存集群和内存集群的数据快速查询。并且具备统一的访问接口，支持快速接口扩展，自动升级部署，灰度发布。

2.2 分布式缓存

缓存集群的数据存储采用分布式内存数据库开源集群模式实现，共部署3台主机，6组节点，每组节点包括一个Master节点（可读写）与一个Slave节点（只可读），各节点之间相互联通，交换彼此的状态信息。主从节点之间的数据同步分为全量与增量两种机制，集群优先尝试增量同步，如果不成功则进行全量同步，无论增量还是全量都是以异步的方式同步数据。增量同步时，主备之间有毫秒级数据延迟，故障时存在少量数据丢失的情况。客户端默认从Master节点读取数据，当Slave节点故障时，对业务无影响，当Master节点出现故障时，集群会重新选举一个Slave节点提升为Master节点（默认10 s），保证业务的正常运行。

2.3 多维度故障检测

多维度故障检测技术实现智能化的内存集群故障检测。本文主要对内存使用率、数据准确率、请求超时率进行分析，确定集群健康指标。

（1）内存使用率

内存集群在启动时，会分配一定大小的内存；集群运行时，会实时检测集群的内存使用情况。当数据存储使用内存和集群运行使用内存的总和大于分配内存的85%时，集群处于亚健康状态。

（2）数据准确率

内存集群的数据是实时更新的，每售出一张票，就产生一条更新余票数据，通过数据同步中间件获取消息并写入内存集群。内存集群数据不准确时，会影响旅客的余票查询。

（3）请求超时率

当客户端向作为服务端的内存集群发出请求时，内存集群会根据请求参数进行余票计算，并快速响应客户端的请求，客户端和服务端均设置了响应超时时间。通过实时采集集群响应时间数据，监控集群请求响应情况，当集群请求响应超时达到一定比例时，集群处于不健康状态。

（4）最大承载请求量

根据业务逻辑复杂程度，内存集群的最大承载请求量不同，最大承载请求量也是内存集群的性能极限，超出此极限，会导致请求超时，或集群宕机。

根据集群内存使用率、数据准确率、请求超时率及最大承载请求量多维度进行故障判定，检测间隔可自定义配置，目前配置为15 s循环检测一次。故障判定结果作为集群故障隔离的触发条件，具体判定流程如图3所示。

2.4 分布式内存数据库

分布式内存数据库将内存划分为若干的数据区域和数据单元，根据数据特点，设置存储规则，可按照一定规则分散存储在多台独立设备的内存中，也可同时存储在所有节点中。

（1）基于车次的余票数据分布式存储

图3 多维度故障检测流程

内存集群提供余票计算服务，基于车次进行分布式存储，将余票计算所需的相关基础数据及车次余票数据存放在内存中。在进行余票计算时，利用分布式系统中的资源定位技术快速检索数据，可以同时计算多个车次的余票，并返回结果，提高了系统的可靠性、可用性和存取效率。同时，分布式存储也便于内存集群节点的扩充，只需要在增加节点后，将集群的数据重新分配即可。

（2）内存分布式计算

在进行余票计算时，直接从内存中读取余票数据，在中央处理器（CPU）中完成余票计算，不存在输入/输出方面的瓶颈。内存集群支持“发站+到站+日期”“查询天数+发站”等多种方式余票查询，同时，内存集群根据请求参数计算出需要计算余票的所有车次，根据车次的余票数据分布式存储规则，将需要计算余票的车次分发到车次数据所在的节点，每个节点只与自己内存单元中关联的数据进行计算，计算完成后汇总到请求所在的节点，将所有结果整理汇总，返回给客户端，完成一次查询请求的余票计算。即一次查询请求是由多个节点“合力”完成的，可以通过扩充集群中的节点数量提升集群处理能力。

3 系统测试

车站余票查询服务系统实现了铁路车站售票窗口、自动售票机、车站大屏、电话订票的余票查询功能，支持多种类型的余票查询，具有通用性、可扩展性。原来使用铁路局集团公司地区中心的查询中心进行余票查询时，车站的大屏余票单次查询时间较长，甚至几十秒、几分钟才能完成一次查询。使用铁路车站余票查询系统进行余票查询，可以将单次查询时间缩短几百倍，满足多个车站同时、实时刷新大屏幕余票信息的需求，降低了对传统的关系型数据库的依赖。系统测试主要分为内存集群初始化性能测试和系统验证性测试两方面。

3.1 内存集群初始化性能测试

内存集群初始化是系统扩展内存集群和集群日常运维的重要操作，其性能影响系统运维的复杂程度及快速进行系统资源扩展的效率。根据内存集群业务特点，内存集群扩建主要包括无数据集群重启、集群数据导入、集群索引创建3项操作；内存集群日常运维包括全量数据集群重启。因此，初始化操作的性能测试内容为以下4项：

（1）无数据集群重启耗时及资源使用情况；

（2）集群初始化导入数据耗时及资源使用情况；

（3）集群创建索引耗时及资源使用情况；

（4）全量数据集群重启耗时及资源使用情况。

内存集群初始化性能测试采用真实的生产数据，内存集群规模为8台机器，每台机器有4个节点，共32个节点组成一个分布式内存集群。结合12306互联网售票系统中内存集群初始化性能及运维需求，测试项及耗时如表1所示，满足预期要求。

表1 内存集群初始化性能测试情况

3.2 系统验证性测试

验证性测试（POC）是指针对客户具体应用的验证性测试，可以真实地模拟用户请求，便于验证系统方案是否满足用户需求。采用Jmeter开源性能测试工具，测试客户端为本地服务器，测试场景为客户端请求车站余票查询接口，测试压力线程数为200条，测试用例为前100个热门发到站查询组合，测试时间为 1 h。

根据日志统计，近几年全国铁路所有车站余票查询总量的最大峰值事务处理量为200次/s，查询结果耗时在秒级。测试预期为系统的每秒事务处理量（TPS）不低于200次，同时，系统响应时间（RT）在秒级以下。

测试结果如图4、图5所示，图4、图5的横坐标表示测试时间，图4的纵坐标表示TPS，单位为次，图5的纵坐标表示RT，单位为 ms。由TPS和RT趋势图可以看出，系统在测试时间1 h内，TPS均值为3 000次左右，远高于系统需求的200次，RT均值为40 ms，由秒级降为毫秒级，整体响应时间趋势平稳，查询结果耗时更短，满足测试预期要求。