實時信息交換技術在地鐵清分系統中的研究與實現

韓宇峰 張嘉嶺

(1.上海華騰軟件系統有限公司,200233,上海;2.上海地鐵運營有限公司,200003,上海∥第一作者,工程師)

1 實時信息交換概述

實時信息交換在銀行、社保、電信、票務、零售等行業有著廣泛的應用。盡管不同行業在業務處理上存在著不同,但其中都有一些共同的屬性和特點,即特定的參與方和傳播模式。

1.1 特定的參與方

交換系統的參與方又稱為交換節點。一個特定的參與方即一個信息交換處理節點。數據交換在相關節點間傳送。例如,清分系統即一個節點,它是整個軌道交通票務系統的中央機構,負責軌道交通車票的發行與管理、交易數據的收集、車票和票務清分、資金清算,黑名單管理等。清分節點在某些聯機交換中作為交易的最初發起方,如運營參數、命令、車站運行模式切換/切換通知、交易數據索取、交通卡黑名單和清分結果等;清分節點在某些聯機交換中作為交易的最終目的方,如交易數據上傳和寄存器數據上傳等。

1.2 傳播模式

每種聯機交換都采用以下兩種模式之一進行傳播:

(1)聯機交互(又稱大圈)交易。采用這種傳播模式交換信息時,本節點不能決定交易成功與否,只能由交易最終的目的方給出,介于發起方和目的方之間的其它節點只是傳遞交易請求和交易應答。對于這種交易,一筆交易可能分成多個階段進行。分成階段的數量是由交易類型的業務含義決定的,稱之為交易或交易類型的階段數。聯機交互的傳播模式如圖1所示。

圖1 聯機交互的傳播模式

圖1中的節點是根據它們在交易中所起的作用而命名。發起方與目的方之間的節點都可稱為轉發方,一筆交易的轉發方可能有多個。(上游)來源節點和下游交換節點是相對于本交易處理節點而言的。其中實線箭頭為請求消息,虛線箭頭為應答消息。

(2)分程傳遞(又稱小圈)交易。采用這種傳播模式交換信息時,信息交換節點在收到交易請求時總是立即返回成功應答,然后向下游交換節點轉發。返回的應答消息僅表明其收到請求消息,沒有業務上的交易是否成功的含義。該交易的處理主要在第一階段中進行,收到應答時僅更新交易狀態。為了和聯機交互的交易處理過程相統一,規定分程傳遞交易的階段數為1。分程傳遞的傳播模式如圖2所示。

圖2 分程傳遞的傳播模式

2 實時信息交換系統的邏輯架構及處理流程

2.1 邏輯架構

實時信息交換系統采用多層結構,這是目前絕大多數信息系統采用的基于分布式計算模式的體系結構。它是將不同層次的功能分散在不同軟件層次上的軟件系統結構。從數據交易的角度來剖析,整個系統可以被劃分成交易傳輸、信息交互和交易處理等3個部分,分別對應通信層、聯機交換層、業務層,如圖3所示。

圖3 實時信息交換系統邏輯架構圖

通信層對TCP/IP協議進行實現,在物理上是獨立的進程。它處理通信協議、通信方式,使其上層的應用與通信協議、方式無關。通信層由通信服務模塊和通信客戶模塊組成。每個通信模塊所用的方式、參數都可以配置,可以靈活地接入采用各類同步/異步、長/短連接的通信方式的外部節點,同時采用消息隊列機制為聯機交換層的運作提供一個統一的系統內部接口。

聯機交換層實現交易傳遞、轉接,同時針對通信故障采用超時控制和存儲轉發。它主要由報文處理模塊、超時控制模塊和存儲轉發模塊組成。其中的報文處理模塊處理來自通信層的交易請求和交易應答,同時調用業務層的相關業務邏輯模塊,實現對數據庫的操作,進行針對交易的業務內容的處理。這些模塊的工作都是基于配置信息的。交換層不關心交易的業務含義,所有的業務邏輯均在業務層的業務邏輯模塊中實現。

業務層并不是一個物理上實際存在的實體子系統,它的引入僅僅是為了方便開發時的分工,它是一組業務邏輯模塊的集合。這些業務邏輯模塊被聯機交換層的模塊調用。業務邏輯是一些標準接口的函數的集合,由這些函數來實現各種交易相應業務內容上的處理邏輯。

2.2 處理流程描述

(1)請求消息。通信服務模塊把從上游節點傳來的交易請求消息發送至請求接收隊列。報文處理模塊從請求接收隊列讀取請求消息。若該請求可直接應答,則生成應答消息,發送到應答發送隊列,否則將請求消息轉發到應答發送隊列;若交易類型表明需要進行超時控制,則將交易記錄發送到超時控制隊列;若交易類型表明需要進行存儲轉發,則將交易記錄發送到存儲轉發隊列。通信客戶模塊從請求發送隊列讀取請求消息,發送給相應節點。

(2)應答消息。通信客戶模塊從請求發送隊列讀取交易請求,發送到相應節點;接收交易應答,發送到應答接收隊列。報文處理模塊從應答接收隊列讀取應答消息。若該應答對應的交易還需要向其它交換節點發送交易請求,則組成新的交易請求,發送到請求發送隊列;若交易類型表明需要進行超時控制,則將交易記錄發送到超時控制隊列;若交易類型表明需要進行存儲轉發,則將交易記錄發送到存儲轉發隊列。若該應答對應的交易最初不是由本節點發起的,則將應答消息轉發到應答發送隊列;若交易類型表明對本交易進行了超時控制,則將交易記錄從超時控制隊列中刪除;若交易類型表明對本交易進行了存儲轉發,則將交易記錄從存儲轉發隊列中刪除。通信服務器從應答發送隊列讀取應答消息,發送給相應節點。

(3)超時控制。每隔一定時間(超時控制時間精度),超時控制模塊從超時控制隊列讀取已經超時了的交易記錄,生成超時應答消息,發送到應答發送隊列;若交易類型表明需要進行超時沖正,則生成沖正請求,發送到存儲轉發隊列。通信服務器從應答發送隊列讀取應答消息,發送給相應節點。

(4)存儲轉發。每隔一定時間(存儲轉發時間精度),存儲轉發進程從存儲轉發隊列讀取已經到下一次轉發時刻的交易記錄,生成該交易的轉發請求消息,發送到請求發送隊列;若本交易尚未達到其交易類型所規定的最大存儲轉發次數,則重新設定下一次轉發時刻,寫回存儲轉發隊列。通信服務端從應答發送隊列讀取應答消息,發送給其連接的遠端主機。

3 實時信息交換系統技術特點

(1)高可靠性。系統的流量控制主要是對消息隊列進行控制。當流量大于系統設置的最大值時,新的請求不再放入正常的處理隊列,而是放入一個特殊處理隊列,對該特殊隊列的內容系統將直接給予失敗應答。這樣,在請求量大于系統最大處理能力時,系統能正常處理設置范圍內的交易,而超出部分給予拒絕,以保證系統仍然可用。

(2)可擴展性。系統在運行一段時間交易量逐漸增大時,可簡單地增加CPU、內存、硬盤或者主機設備等硬件實現擴容,增加處理能力,而無需更改應用。另外還可以重新設置一些接入節點的通信配置,使其連接到新增的通信服務器上,達到擴容目的。

(3)可管理性。對通信服務模塊、通信客戶模塊,采用文件配置的方式配置成多進程方式、異步、同步、長連接、短連接;對數據報文可以配置同步頭等信息;對報文處理模塊采用數據庫表的配置方式配置交易類型、交易階段數、傳播類型等。

(4)安全性。通過對操作員的授權來進行應用安全控制,通過對接入系統IP地址的檢查來進行網絡安全控制。檢查接入的IP地址是否在配置表中存在,對接收的報文進行MAC驗證,對發送的報文生成MAC(Media Access Control,介質訪問控制)以讓對方節點進行驗證,從而控制傳輸安全。

4 實時信息交換系統的實現

4.1 數據結構定義

在設計系統時,首先定義貫穿整個系統的全局結構體。每筆交易進入系統后,此交易的數據信息和對此交易進行業務處理,以及存儲轉發所需的控制信息,均存放于此結構體的變量 txnInfoDef中(見表 1)。

4.2 模塊功能

(1)通信服務模塊:接受外界的連接請求,建立通信連接,接收數據請求報文,發送數據請求包給報文處理模塊;接收數據應答包,發送數據應答報文。對于同步短連接,通信服務模塊只用1個子進程進行請求報文的接收和應答報文的發送。通信服務模塊啟動時,根據環境變量APP_CFG_FILE得到配置文件的全路徑名,根據命令行參數得到配置文件中的配置項的節名,并讀取該節中的配置項,得到具體的工作配置。通信服務模塊以任何方式工作時,都不主動斷開連接,僅當發現對方斷開連接時,才關閉連接。

(2)通信客戶模塊:從報文處理模塊接收數據請求包,向外部系統發送數據請求報文;從外部系統接收數據應答報文,發送數據應答包。對于同步連接,通信客戶模塊只用1個子進程進行請求報文的接收和應答報文的發送。

(3)報文處理模塊:處理來自外部系統的數據請求包,把數據請求包或數據明細存放到數據庫,同時調用相關的業務邏輯處理函數對相應的交易進行處理,并發送至相應的消息隊列。

表1 數據結構定義

(4)存儲轉發模塊:對于分程傳遞交易,交易接收方不能及時返回應答時,存儲轉發模塊會重復發送交易請求。存儲轉發模塊讀取指令,根據指令要求從數據庫取出數據請求包,把數據請求包發送到通信客戶端。

(5)超時控制模塊:交易接收方不能及時返回應答時,超時控制模塊會生成超時應答包,發送到對應接收方的消息隊列中。超時控制模塊從消息隊列讀取控制消息,如果是超時控制請求,則對該請求消息進行超時控制;如果是撤消超時控制請求,則撤消對請求消息的超時控制。對發生超時的請求消息,生成超時應答包,發送到對應接收方的消息隊列中。

(6)安全模塊:確保消息報文內容在傳輸過程中沒有被篡改。

4.3 業務邏輯的實現

業務邏輯是一些標準接口函數的集合,將交易的業務處理內容封裝在這些函數中,實現各種交易的相應的業務內容上的處理。

(1)判斷交易類型(getTxnType):報文處理模塊收到請求消息時被調用,它用于在交易請求消息報文的相應位置上取得交易類型。該函數以指向txnInfoDef結構變量的指針為參數。得到的交易類型代碼(或關鍵字)放在 txnInfoDef結構變量的txnType字段中返回。

(2)請求處理時的業務邏輯(bizLogicReq):報文處理模塊處理交易請求時被調用,根據交易類型,對交易及相關的業務信息進行處理,包括向相關業務信息表插入、更新、刪除記錄,觸發一些業務內容處理進程的運行等。該函數以指向txnInfoDef結構變量的指針為參數。若交易僅有一個階段(分程傳遞的交易),并且處理中未發生任何失敗,txnInfoDef結構變量的resultReason和result字段會被分別置成 RC_SUCCESS(成功)和‘S'。

(3)應答處理時的業務邏輯(bizLogicReply):報文處理模塊處理交易應答時被調用,它根據交易類型,對交易及相關的業務信息進行處理。

(4)判斷路由(getRoute):報文處理模塊處理交易請求或交易應答時被調用,根據該交易類型配置和交易具體信息得到下一步的路由。該函數以指向txnInfoDef結構變量的指針為參數。得到的路由節點標識放在txnInfoDef結構變量的routeNode數組元素中返回,同時 txnInfoDef結構變量的routeNodeNum字段被設置成路由節點的數量。

(5)生成應答(genReply):報文處理模塊處理交易請求、超時控制模塊處理超時交易時被調用,它用于生成交易的失敗(如目的方不可到達、下游節點應答超時等)應答消息報文。該函數以指向txnInfoDef結構變量的指針為參數。生成的應答消息報文存放在數據庫的交易消息表中,同時還存放在txnInfoDef結構變量的 outMsg中返回,outMsgLen字段被置成應答消息報文長度(字節數),outPkgNo字段被置成 0(包號為 0),outPkgNum字段被置成1(僅有1包)。

(6)生成轉發請求(genFw rdReq):報文處理模塊處理交易請求或交易應答時被調用,生成交易的下一步需要轉發出去的請求消息報文。該函數以指向txnInfoDef結構變量的指針為參數。生成的交易請求消息報文存放在數據庫的交易消息表中。同時,最后一包存放在 txnInfoDef結構變量的outMsg中,outMsgLen字段被置成最后一包的報文長度(字節數),outPkgNo字段被置成最后一包的包號,outPkgNum字段被置成消息包數。

(7)生成轉發應答(genFwrdReply):報文處理模塊處理交易應答時被調用,生成交易的下一步需要轉發出去的應答消息報文。該函數以指向txnInfoDef結構變量的指針為參數。生成的交易應答消息報文存放在數據庫的交易消息表中。同時,最后一包存放在 txnInfoDef結構變量的 outMsg中,outMsgLen字段被置成最后一包的報文長度(字節數),outPkgNo字段被置成最后一包的包號,outPkgNum字段被置成消息包數。

(8)生成目的方應答(genHomeReply):對于聯機交互傳播模式的交易類型的交易,報文處理模塊處理交易請求時,若發現本節點就是該交易的目的方,則通過調用本函數來生成本節點作為交易目的方給出的應答消息報文,查詢賬戶信息,組成所需的應答消息報文。該函數以指向txnInfoDef結構變量的指針為參數,生成的交易請求消息報文存放在數據庫的交易消息表中。同時,最后一包存放在txnInfoDef結構變量的outMsg中,outMsgLen字段被置成最后一包的報文長度(字節數),outPkgNo字段被置成最后一包的包號,outPkgNum字段被置成消息包數。

4.4 數據庫的實現

數據庫根據大數據量的特定,采用按天建表、按批次分區的建表原則。數據庫主要有如下表組成:

(1)交易日志表(TBL_FEP_TXN_LOG),用于存放本交換節點處理的交易記錄,每筆交易對應一條數據表記錄。

(2)交易消息表(TBL_FEP_TXN_MSG),用于存放本交換節點接收到的和發送出去的消息報文。每筆交易對應若干個交易消息,而每個交易消息又由若干個包構成,每個消息包對應本表的一條記錄。

(3)交易類型表(TBL_FEP_TXN_T YPE_INFO),用于定義交易類型的階段數。本表的每一條記錄對應一種交易類型。

(4)交易類型階段表(TBL_FEP_TXN_T YPE_PHASE),用于定義交易類型的各階段的行為。本表的每一條記錄對應某一種交易類型的一個階段。

(5)分程傳遞交易類型表(TBL_FEP_TXN_T YPE_RELAY),用于定義交易類型在進行分程傳遞時的行為。本表的一條記錄對應某一種交易類型的分程傳遞部分。

(6)節點信息表(TBL_FEP_NODE_INFO),用于存放各節點信息,如線路、車站等。

(7)一票通交易數據表(TBL_FEP_TICK_YYYYMMDD),存放由線路中央上傳的一票通待清分交易數據,按包存放。該類數據的數據量大,處理速度要求較低,與其它消息分開存放。同時考慮到數據訪問的效率,該表按清分日期每天建表。

(8)公共交通卡交易數據表(TBL_FEP_CARD_YYYYMMDD),存放由線路中央上傳的公共交通卡交易數據,按包存放。該類數據的數據量大,處理速度要求較低,與其它消息分開存放。同時考慮到數據訪問的效率,該表按清分日期每天建表。

5 應用實例

軌道交通清分中心計算機系統(簡稱清分系統)完成全路網的車票發行與調配管理、換乘交易清分與帳務結算、路網運營模式監控、各類交易信息和客流信息的統計分析等功能。前置信息交換子系統作為清分系統的重要組成部分,對外提供通信接入服務。前置信息交換子系統是一種典型的實時信息交換系統,負責向線路中央系統、公共交通一卡通中心、結算銀行等提供網絡聯接、記錄日志,支持售票交易、進出站交易等的接入以及交通卡相關交易的轉接和相關文件的發送。任何直接與清分系統主機有信息往來的外部機構節點都通過該子系統接入清分系統。并且該子系統接收外界發來的交互請求,經過其內部的處理,返回交互的應答。其內部的處理因交互請求的類型不同而各異。例如,對于線路中央上傳的交易數據,處理內容是插入數據庫;而對于線路中央發來的車站運行模式切換通知,處理內容是記錄到數據庫后再向其他各個線路中央主機轉發。前置信息交換子系統與其它子系統協同工作,共同完成各種業務和交易的處理,構成軌道交通清分系統的有機整體。

實時信息交換技術已成功運用于上海軌道交通清分系統前置信息交換子系統中。系統每天處理500余萬筆交易,系統運行穩定。

[1]Richard Stevens W,楊繼張.UNIX網絡編程(第2卷):進程間通信[M].2版.北京:清華大學出版社,2000.

[2]葉寧.Unix環境下利用Socket和消息隊列構建應用通信平臺[J].華南金融電腦,2002(11):85.

[3]簡廣林,王穎.利用消息隊列實現三層結構的通信平臺[J].現代電力,2003(2):72.

[4]上海軌道交通票務中心.城市軌道交通自動售檢票系統專用技術說明[G].上海,2006.