陳松楠

(信陽農林學院 信息工程學院，河南 信陽 464000)

0 引言

現有基金登記結算系統大部分采用C/S的體系結構，如圖1所示，這種體系結構雖然能夠充分利用兩端的軟硬資源，但卻增加了客戶端接入成本，系統對于登記地點、環(huán)境多有要求，在異構環(huán)境下甚至難以實現客戶端與服務器互聯互通[1]?，F有基于C/S架構的基金登記結算系統也并沒有涉及大量實時數據并發(fā)訪問，數據處理多依靠數據庫管理系統自身機制。

圖1 客戶機/服務器系統架構

在基于三層架構的基金登記結算系統中，IBM公司的消息中間件WebSphere MQ使用最為普遍。消息、隊列、隊列管理器、通道是構成MQ的幾個重要對象，其中，隊列管理器是最為重要的一個部件，它管理控制不同的消息隊列實現遠程通信[2]。隊列管理器是為應用程序提供消息服務的機構，網絡中每一個隊列管理器的名字必須唯一，一個隊列管理器可以包含很多不同類別的隊列，但是一個隊列只能屬于一個隊列管理器，兩個遠程隊列管理器之間通過代理通道相互傳遞消息[3]。在消息傳遞的過程中，作為信息存儲的載體，消息隊列按照不同的功能分成不同的類別，這和基于高級消息隊列協議的消息中間件區(qū)別較大[4]。MQ依靠消息頭中所含的路由信息來實現數據的正確傳送，消息路由信息由目標隊列名和隊列管理器名組成，整個消息路由過程如圖2所示。服務進程C在處理完成一個請求之后，返回一個確認給消息通道，請求進程將已經處理的消息從隊列中刪除，服務進程通過get方法從隊列中不斷地獲取未處理的消息。

圖2 消息在WebSphere MQ中的路由過程

1 基于交易內容的消息路由方法

新模式下基金登記結算系統改變了現有兩層實現的體系結構，采用C/S/S的三層體系結構[5],如圖3所示。應用程序之間高效透明的數據傳送由消息中間件負責，實時交易業(yè)務的完整性由交易中間件保證。在三層或多層體系結構中最重要的部件就是中間件。中間件可以看做一個獨立的應用軟件，它封裝了底層硬件的實現邏輯，具有強大的通信能力和良好的擴展性，同時為上層軟件提供接口，使程序開發(fā)者可以專注于業(yè)務邏輯的實現而不必在底層實現上浪費時間，數據高效透明傳送以及交易完整性保障這兩大功能也可以封裝在一個應用實現。

圖3 基于中間件的三層體系結構

1.1 高級消息隊列協議通信實現過程

高級消息隊列協議基本域模型通信原理[6]可以用圖4來描述，從圖中可以看到交換器和消息隊列構成了Broker的基本單元，其被定義為虛擬主機(Virtual Host)。一個Virtual Host里面可以有若干個Exchange和Queue，但是權限控制的最小粒度是Virtual Host?？蛻舳顺绦蛳胍虰roker溝通就必須建立起與Broker的連接，這種連接是與虛擬主機相關聯的，其本質是客戶端程序到Broker的TCP連接?？梢栽谝粋€連接上并行多個通道，每一個通道執(zhí)行與Broker的通信[7]，如果在大量數據請求的情況下，暫且不考慮TCP連接是否浪費，單論操作系統也無法承受每秒建立如此多的TCP連接。高級消息隊列協議規(guī)定只有通過通道應用程序才能執(zhí)行相關命令，因此僅僅建立了客戶端到Broker的連接后，客戶端還是不能發(fā)送消息的，還需要為每一個連接建立起通道，之后才能調用命令。

圖4 高級消息隊列協議模型層通信實現過程

在會話層，為上層所需要交互的每個命令分配一個唯一標識符，以便在傳輸過程中可以對命令做校驗和重傳。命令發(fā)送端也需將每個發(fā)送出去的命令記錄到重發(fā)緩沖區(qū)，以期得到接收方的回饋，保證這個命令被接收方明確地接收或是已被執(zhí)行。對于超時沒有收到反饋的命令，發(fā)送方再次重傳。如果接收方已明確地回饋信息想要告知命令發(fā)送方，但這條信息在中途丟失或是其他原因發(fā)送方沒有收到，那么發(fā)送方不斷重傳會對接收方產生影響，為了降低這種影響，命令接收方可以設置一個過濾器，來攔截那些已接收過的命令。

1.2 基于交易內容的消息路由方法

一個虛擬主機中會存在多個消息隊列，交換器要做到將消息準確發(fā)送到相應的消息隊列中。消息隊列的創(chuàng)建是由客戶端程序控制的，在創(chuàng)建消息隊列后需要確定它來接收并保存哪個交換器路由而來的結果，綁定就是用來關聯交換器與消息隊列的域模型。在與多個消息隊列關聯后，交換器中就會存在一個路由表，這個表中存儲著每個消息隊列所需要消息的限制條件。在每次收到客戶端請求消息后交換器就會檢查它接收到的每個消息的消息頭和消息體信息，來決定將此消息路由到哪一個隊列中去。

消息中間件域模型核心服務根據用戶程序中定義的交換器類型為消息提供不同的路由機制，當投資者發(fā)起基金申購、贖回交易業(yè)務時，在應用程序中標記此類請求消息消息頭的RoutingKey值為Buy，定義交換器類型為Direct，如圖5所示。在某一時刻生產者進程發(fā)出的消息被傳送到交換器，交換器首先檢查消息頭的RoutingKey屬性，并在路由表中查找匹配，路由表中記錄了用于綁定交換器和隊列的BindKey的值，在此要特別注意的是，交換器可以和某一消息隊列有多個綁定值，也就是說消息路由關鍵字的消息可以傳送到一個消息隊列之中，通過精確匹配消息的路由關鍵字，將消息路由到零個或者多個隊列中，客戶端程序在每一個隊列端又定義了一個或多個相對應的消費者，這樣就把生產者和對應的消費者聯系了起來。根據Direct類型交換器進行進程通信時的路由規(guī)則，可以構建經典的點對點隊列消息傳輸模型[8]。從圖5可以看出，當某個客戶端消息到達交換器X時，此消息的RoutingKey為Buy，將消息發(fā)往消息隊列Q1。

圖5 交換器為Direct屬性下基金申購數據路由規(guī)則

每日基金清算過程中，要處理大量的當日賬戶數據和交易數據，清算任務雖然沒有實時性的要求，但是卻涉及大量表處理操作，清算過程中的每一步又可以分成許多子處理步驟?？梢栽O定交換器為topic即主題類型，根據清算工作的復雜程度來分發(fā)相應的處理程序。其本質上就是利用模式匹配來實現消息和相關處理隊列的綁定過程。

這種消息路由器機制可以被用來支持經典的發(fā)布/訂閱消息傳輸模型，使用消息路由關鍵字中定義的主題名字空間作為消息尋址模式，將消息傳遞給那些部分或者全部匹配主題模式的消費者[9]。此種模式下綁定關鍵字由零個或多個標記構成，每一個標記之間用“.”字符分隔，綁定關鍵字必須用這種形式明確說明，并支持通配符“*”匹配一個詞組，“#”匹配零個或多個詞組。如圖6所示，首先在客戶端程序定義交換器為主題式類型，圖例中定義了“#.Acct.*.*”、“*.Acct.#”和“*.Acct.*”三個綁定關鍵字,它們分別對應了消息隊列Q1、Q2和Q3，當帶有路由關鍵字“CPrep.Acct.Clear”的消息，也就是賬戶清算處理前的請求傳送到主題式交換器時，查找路由表后與“*.Acct.#”、“*.Acct.*”匹配，但不與“#.Acct.*.*”匹配，因此消息傳送到Q2和Q3隊列。

圖6 基金清算過程中基于主題的消息路由規(guī)則

每日日終，當日清算工作處理完成之后，基金登記結算系統會向電商系統發(fā)送投資者的收益數據，在應用程序設計定義交換器類型為fanout即廣播類型。它實現了這樣的消息路由機制:不論消息路由關鍵字RoutingKey值是什么，這條消息都會被路由到所有與該交換器綁定的消息隊列中，如圖7所示。廣播式交換器類型的工作方式如下：不使用任何參數將消息隊列與交換器綁定在一起，也就是說在客戶端程序中不用設置任何BindKey的值，當發(fā)布者(在此種模式下直接式交換器類型描述中的producer變成了publisher，已經隱含了兩種交換器類型的區(qū)別)向交換器發(fā)送一條消息，此消息將被無條件地傳遞到所有和這個交換器綁定的消息隊列中。在圖7中，從客戶端進程P發(fā)送到交換器X的所有消息，將被送到所有和交換器綁定的Queue上，消息隊列Q1、Q2和Q3都能收到P發(fā)送的消息，也即是投資者都能查看到相應的基金收益數據。

圖7 交換器在廣播屬性下的基金收益數據路由規(guī)則

2 實驗結果與性能分析

電商系統實時將投資者的開戶、申購、贖回等請求數據傳送到基金登記結算系統，系統對數據處理后，實時給出應答消息。本節(jié)對系統在LoadRunner壓力測試工具[10]下模擬開戶、申購、贖回，分析基于中間件的開放式基金登記結算系統在一定數量的并發(fā)請求過程中，消息中間件和交易中間件CPU的使用率以及系統處理每個事物的平均響應時間。

基金開戶性能測試的過程中，平均事務響應時間如圖8所示。在平均每秒開戶185筆時，消息中間件和交易中間件的CPU使用率在1%～8%之間，內存使用率在2%～7%之間。

圖8 在60個投資者并發(fā)開戶情況下平均事務響應時間

基金申購性能測試的過程中，平均事務響應時間如圖9所示。在已有680萬賬戶存量，平均每秒申購交易267筆情況下，消息中間件和交易中間件的CPU使用率在1%～8%之間，它們的內存使用率在2%～7%之間。

圖9 在60個投資者并發(fā)申購情況下平均事務響應時間

基金贖回性能測試的過程中，平均事務響應時間如圖10所示。平均每秒發(fā)起307筆贖回交易，系統消息中間件和交易中間件的CPU使用率在1%～8%之間，內存使用率也在1%～8%之間。

圖10 在60個投資者并發(fā)贖回情況下平均事務響應時間

3 結論

本文介紹了面向登記結算系統的消息路由方法的實現過程。首先，分析了現有基金登記結算系統中間件的三層體系結構，并對基于此體系結構實現的基金登記結算系統的應用層次進行了介紹。其次，分析了高級消息隊列協議應用通信實現過程，并在此基礎上提出了基于基金交易內容的三種消息路由方法。最后，對基金登記結算系統進行性能測試，通過LoadRunner模擬在大量并發(fā)數據下系統對實時交易申請數據的響應，并對每日日終完成清算流程各步驟所需要時間進行測試。實驗結果表明該系統基本能滿足基金結算的需求。

[1] BERTOCCO M, FERRARIS F, OFFELLI C, et al. A client-ser ver architecture for distributed measurement system[J]. IEEE Transactions on Instrumentation and Measurement Technology,1998,47(5): 1143-1148.

[2] SANCHER T. IBM MQ series and WebSphere MQ interview questions[M]. New York： Equity Press,2007.

[3] DAVIES S, COWEN L, PARKER H. WebSphere message broker basics[M]. New York: International Business Machines Corporation, 2005.

[4] VINOSKI S. Advanced message queuing protocol[J].IEEE Internet Computing, 2006,10(6): 87-89.

[5] MAHMOUD Q. Middleware for communications[M].Chichester: John Wiley & Sons Ltd, 2004.

[6] HINTJENS P. ZeroMQ: messaging for many applications[J]. O’Reilly Media, 2013, 23(1): 646-652.

[7] LUI M, GRAY M, CHAN A, et al. Enterprise messaging with JMS and AMQP[M]. Pro Spring Integration, 2011.

[8] 李知杰. 基于AMQP的異步通信實現及其在OpenStack項目中的應用[J].軟件導刊，2013, 12(7)：35-37.

[9] 楊萍，李杰. 利用LoadRunner實現Web負載測試的自動化[J].計算機技術與發(fā)展，2007, 17(1): 242-244.

[10] 余益民. 統一全國證劵登記結算系統的探討[J].中國金融，2010(3): 30-33.