鐵路車站余票查詢服務系統設計與實現

王思宇，梅巧玲，馬 杰，梁曉慷

（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節點（只可讀），各節點之間相互聯通，交換彼此的狀態信息。主從節點之間的數據同步分為全量與增量兩種機制，集群優先嘗試增量同步，如果不成功則進行全量同步，無論增量還是全量都是以異步的方式同步數據。增量同步時，主備之間有毫秒級數據延遲，故障時存在少量數據丟失的情況?？蛻舳四J從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，由秒級降為毫秒級，整體響應時間趨勢平穩，查詢結果耗時更短，滿足測試預期要求。

圖4 TPS 趨勢

圖5 RT 趨勢

4 結束語

目前，車站余票查詢服務系統已應用在全國鐵路的售票窗口、自動售票機、車站大屏及集中電話訂票系統中，為車站售票提供可靠、安全的服務。隨著互聯網技術的不斷發展、客票系統的架構優化，車站余票查詢服務系統也將進行架構調整、技術革新，不斷提高系統的穩定性和可靠性。