梅巧玲，李天翼，馮 焱

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

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

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

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

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

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

1.1 規(guī)則引擎

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3 系統(tǒng)相關(guān)技術(shù)

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

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

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

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

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

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

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

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

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

表2 常用負(fù)載均衡策略總結(jié)

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

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

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

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

5 結(jié)束語

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