梅巧玲，李天翼，馮 焱

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

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

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

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

1 基于規(guī)則引擎的數(shù)據(jù)審核機制

在鐵路12306互聯(lián)網售票系統(tǒng)的支付業(yè)務中, 數(shù)據(jù)審核是確保支付數(shù)據(jù)真實性、可靠性、正確性和完整性的重要環(huán)節(jié)。在建立數(shù)據(jù)審核機制時，主要采用規(guī)則引擎實現(xiàn)電子支付數(shù)據(jù)的審核功能。

1.1 規(guī)則引擎

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

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

表1 業(yè)務規(guī)則列表

1.2 配置業(yè)務規(guī)則

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

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

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

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

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

圖1 業(yè)務規(guī)則判定流程

2 數(shù)據(jù)審核系統(tǒng)及其功能

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

圖2 電子支付數(shù)據(jù)審核系統(tǒng)架構圖

2.1 電子支付數(shù)據(jù)存儲模塊

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

2.2 電子支付數(shù)據(jù)同步模塊

電子支付數(shù)據(jù)同步模塊實現(xiàn)了電子支付業(yè)務數(shù)據(jù)同步，由關系型數(shù)據(jù)庫產生后，將數(shù)據(jù)通過復制服務器、數(shù)據(jù)同步服務器以及消息服務器實時傳輸?shù)郊褐?，將其少量?shù)據(jù)和全量數(shù)據(jù)分別同步至分布式內存數(shù)據(jù)集群和分布式Hadoop數(shù)據(jù)集群中。

2.3 電子支付數(shù)據(jù)高效存儲運算模塊

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

2.4 電子支付數(shù)據(jù)審核功能模塊

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

3 系統(tǒng)相關技術

3.1 高頻數(shù)據(jù)存儲

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

圖3 電子支付數(shù)據(jù)金字塔存儲模式

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

圖4 高頻數(shù)據(jù)字段存儲方式

3.2 Hadoop數(shù)據(jù)存儲

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

3.3 負載均衡優(yōu)化

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

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

4 系統(tǒng)性能測試

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

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

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

5 結束語

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