12306 互聯網售票系統余票數據一致性保障技術方案研究

李 楊，李 雯，胡志鵬，戴琳琳

（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互聯網售票系統相關數據的統計，該方案可顯著提高余票查詢數據一致性，大幅降低因余票問題導致的旅客投訴率，應用效果顯著。