客票電子支付數據審核系統的研究

梅巧玲，李天翼，馮 焱

（中國鐵道科學研究院集團有限公司 電子計算技術研究所，北京 100081）

鐵路客票開啟電子支付業務以來，電子支付筆數不斷增多，2019年春運期間，鐵路12306互聯網售票系統的每日最大售票能力提升至1 500萬張，伴隨著電子支付業務的并發壓力不斷增大。當用戶在支付期間出現網絡崩斷、系統宕機、鐵路客運組織調度或其他不可抗力的意外情況時，有可能引發用戶遭遇重復支付、支付后未出票以及銀行退款失敗等現象，這對用戶購票體驗造成了極大的影響。

為了能夠保證用戶安全順暢地完成電子支付流程，建立符合鐵路特點的電子支付數據審核機制十分必要。當前，在大數據審核機制方面，銀行、票務以及醫院等行業都做出相應研究。在高并發銀行ATM前置處理（ATMP）系統中，主要通過建立多指數沖正緩存機制加強系統魯棒性，提高業務效率[1-3]。在票務方面，緩存服務器集群中的多個線程競爭訪問權限，這有效降低了在高并發壓力下外部票務系統的訪問壓力[4-6]。以上研究方案雖然一定程度上解決了電子數據審核問題，但是對于業務流程復雜以及業務量巨大的鐵路客票電子支付數據來說，并不完全適合[7]。

本文主要研究在電子支付流程的動態業務環境中，進行規則引擎的定義和業務規則的配置，搭建電子支付數據審核體系。通過系統性能測試，驗證了該電子支付數據審核機制可以為用戶的電子支付體驗提供安全順暢的保障。

1 基于規則引擎的數據審核機制

在鐵路12306互聯網售票系統的支付業務中, 數據審核是確保支付數據真實性、可靠性、正確性和完整性的重要環節。在建立數據審核機制時，主要采用規則引擎實現電子支付數據的審核功能。

1.1 規則引擎

規則引擎技術是根據規則中設置的條件,對業務數據進行匹配,從而決定是否執行后續動作的技術。規則引擎是應用程序中的一個組成部件，它的作用是將應用程序代碼中隨著空間和時間動態變化的部分業務規則剝離出來，在事先定義的語義模塊基礎上編寫業務規則決策方案。在系統需要時由業務管理人員進行配置和管理，對業務系統的數據進行輸入和編輯，解釋業務規則的同時根據業務規則做出決策引擎。規則管理系統根據業務系統提供查詢的入口參數以及相應的業務需求信息，對請求信息進行處理反饋[8]。

規則管理系統向業務系統發送請求消息，業務系統再將請求轉發給規則引擎。規則引擎根據服務號將請求信息分配給相應的服務處理模塊，以作出準入判斷：如果服務信息觸發了服務的準入或拒絕條件，則系統不直接將判斷結果反饋到業務接口；如果該請求不符合規則引擎的條件，則對業務系統進行規則觸發，最終將決策結果反饋到業務系統[8]。規則的觸發條件，系統對于符合規則條件的可按照規則設定的優先級別返回編碼。業務規則可以分批管理，在每個批次中可以設定規則之間的優先等級，同時，對于不同的規則批次也可以設置優先級[8]。業務規則主要從售票業務規則、退票業務規則和改簽業務規則3方面進行說明，如表1所示。

表1 業務規則列表

1.2 配置業務規則

業務規則判定流程如圖1所示。由圖1可知，每個規則中的條件可以通過優先級判斷來設置，也可以設置成相同的優先級并行運算。

業務規則是用于維持業務結構和控制業務行為的業務描述。業務規則描述業務流程中核心的、有價值、有意義的對象、關系和活動[8]。業務規則主要包括兩個方面：（1）建立特征審核規則；（2）建立數據審核規則。

（1）特征審核規則的作用是對電子支付數據進行合法性檢查，如身份證、售票處代碼、操作員賬號、購票人信息、數據格式、數據長度、必填數據項等，這些內容需符合對象的基本特征格式。特征審核機制通過各種正確表達式在客戶端和后端接口進行形式上的合法性驗證。

（2）數據審核規則的功能是對電子支付數據根據業務規則進行校驗審核。數據查看規則將電子支付數據與服務器端設定的業務規則進行驗證，并根據比較結果來核實數據的正確性和合法性。

規則引擎可用于根據業務需求創建、修改和刪除操作單個業務規則，是解析、調用、執行規則包的服務。每個規則應有相應的編碼，編碼可以由用戶自行設定，在滿足規則/不滿足規則時也可以設定

圖1 業務規則判定流程

2 數據審核系統及其功能

在大數據電子數據存儲與負載均衡算法優化實現的基礎下，搭建了如圖2所示的電子支付業務數據審核系統。電子支付數據審核系統在旅客在購票支付環節中出現問題時，對支付數據進行審核校驗功能，及時修復反饋故障。該系統分為4個模塊，按照順序分別為：（1）電子支付數據存儲模塊；（2）電子支付數據同步模塊；（3）電子支付數據高效存儲運算模塊；（4）電子支付數據審核功能模塊。

圖2 電子支付數據審核系統架構圖

2.1 電子支付數據存儲模塊

電子支付數據存儲模塊實現了電子支付數據存儲，高頻訪問的數據放到內存中，全量數據放到分布式Hadoop集群中，這些數據都是由關系型數據庫產生的。該模塊使得電子支付業務數據有據可審，降低了位于最深層次安全網絡結構中關系型數據庫被直接操作與訪問的次數。

2.2 電子支付數據同步模塊

電子支付數據同步模塊實現了電子支付業務數據同步，由關系型數據庫產生后，將數據通過復制服務器、數據同步服務器以及消息服務器實時傳輸到集群中，將其少量數據和全量數據分別同步至分布式內存數據集群和分布式Hadoop數據集群中。

2.3 電子支付數據高效存儲運算模塊

電子支付數據高效存儲運算模塊實現電子支付數據的高效存儲與運算兩大重要功能，由分布式內存數據集群和分布式Hadoop集群組成，內存數據集群負責數據運算和存儲，Hadoop集群負責數據存儲，對接電子支付數據審核功能接口，對負載均衡優化算法分配的請求進行處理與反饋。為最大程度提高查詢性能，將關系型數據庫中的唯一索引設置為Hadoop集群的rowkey，客戶端進行查詢時，通過login_name模糊匹配，再通過訂單號等其他條件拼接rowkey來獲取數據。

2.4 電子支付數據審核功能模塊

電子支付數據審核功能模塊主要通過常用的計算機語言函數實現對電子支付數據預警、反饋和調整。當生成電子支付數據時，電子支付數據審核功能接口會按照電子支付數據關鍵字段隊列以固定頻率輪流進行數據對比，主要檢查銀行服務提供的數據是否與存儲在關系型數據庫的根數據相同。當用戶在支付過程中出現重復支付以及退款失敗等問題時，固定頻率的輪詢審核可以在用戶提出投訴之前便提供消息預警與反饋，提示相關客服人員對該筆交易進行關注并處理，隨后客服人員通過數據審核系統提供的接口進行調整操作。

3 系統相關技術

3.1 高頻數據存儲

鐵路客票電子支付業務數據審核機制的審核信息以多字段信息的形式進行存儲，為了能夠快速地對海量數據信息進行增加、刪除、修改、查詢，使用分布式內存數據庫和Hadoop技術作為數據庫基礎架構，數據結構采用金字塔數據關系模型，保證了數據審核系統的業務效率。圖3所示為電子數據存儲的金字塔形數據關系模式，該模式自上而下的數據集關系為上層屬于下層的子集，少量高頻數據存放在分布式內存數據庫中，全量數據存儲在Hadoop數據集群中，關系型數據集是上面兩層數據的提供者，該金字塔型數據關系模式可以縮減內存數據集中的不必要信息，降低資源消耗，提高查詢效率。

圖3 電子支付數據金字塔存儲模式

電子支付業務高頻數據字段的存儲運算模塊通過分布式內存數據庫技術實現，分布式內存集群由多個分散布局的Server節點構成，如圖4所示，不同數據節點部署在不同的服務器上。Server節點由內聯的多個存儲區域構成，常用的數據比如車站數據、車次數據、停靠站數據，這些數據服從一致性Hash理論分別存儲在不同的存儲單元中，當需要對電子支付高頻數據字段進行運算時，內存數據庫集群可以同時調用多個節點進行計算，每個節點的運算對象只是從屬于自身的數據存儲區域，這在一定程度上可以避免數據被跨網絡讀取，所有Server節點運算匯總結果將被匯總到某一個節點上。

圖4 高頻數據字段存儲方式

3.2 Hadoop數據存儲

Hadoop數據集將電子支付業務數據切分成文件塊，分散存儲在Hadoop分布式文件系統（HDFSH）的不同DataNode節點上，使其服從列導向存儲機制數據庫的區域原則，同時，把電子支付業務數據的標志字段作為劃分標準，利用HDFS將文件塊分散地部署在不同的DataNode中。HDFS可以保證電子支付業務數據的存儲準確性和一致性，因為NameNode存有數據的版本信息，當對DataNode中的電子支付業務數據進行讀寫操作時，會自動校驗相同數據不同NameNode對應的版本是否一致，如果不一致則會觸發恢復校正。為了能夠在有限的資源內最大程度提升數據審核輪詢性能，將列導向存儲機制數據庫的行鍵設置為關系型數據庫的唯一索引。當數據審核系統輪詢查找時，將通過電子數據的關鍵字段信息進行模糊匹配，再通過其他字段信息對行鍵進行完整拼接，從而獲得查詢目標。

3.3 負載均衡優化

鐵路客票電子支付業務的服務器資源有限，必須使用符合鐵路特色的負載均衡算法并合理搭配上述數據集群才能最大化展現服務器性能。目前，常用的簡單負載均衡算法如表2所示，各均衡算法都有優缺點，需要根據服務器集群狀況定制適宜的負載均衡策略。電子支付業務數據審核系統使用的服務器集群性能分為高、中、低3檔，在處理同一請求過程中，不同性能擋位服務器的平均響應時間、當前帶寬以及當前請求連接數均有差異[9-11]，在此，提出了加權隨機算法與基于平均響應時間、當前帶寬、CPU利用率以及當前請求連接數4因素加權最小策略相結合的雙層負載均衡動態反饋方案。

表2 常用負載均衡策略總結

4 系統性能測試

數據審核系統使用jmeter工具對其進行壓力測試，其中，系統吞吐量（TPS）、CPU利用率以及響應時間（RT）是衡量系統性能的重要指標。旅客出行構成的電子支付業務量具備周期性規律，分別對10臺服務器、30臺服務器以及60臺服務器進行系統性能測試。具體測試結果如圖5所示。

圖5 不同服務器數量集群CPU利用率、RT和TPS的變化趨勢

從圖5可以看出，在不同服務器數量的情況下，隨著查詢量TPS的增加，系統響應時間RT先呈現下降又出現向上增長趨勢，從而得出服務器數量在30臺左右時，系統平均響應時間良好，系統吞吐量也處于優良狀態范圍內，基本滿足應用的要求。

5 結束語

為解決旅客在鐵路客票電子支付業務流程中遭遇的重復支付、支付后未出票、銀行退款失敗等問題，運用分布式內存數據庫技術以及Hadoop技術，搭建了電子支付數據審核系統。通過對不同部署服務器數目的數據審核系統進行壓力測試，驗證了該數據審核系統在CPU利用率處于正常狀態下系統具備良好的吞吐量以及響應時間。在2019年春運期間，該系統試運行結果表明，電子支付數據審核系統具備提高鐵路客票電子支付數據業務的能力，能夠保障旅客擁有良好的出行購票體驗。