基于中間件的開(kāi)放式基金登記結(jié)算系統(tǒng)

陳松楠

(信陽(yáng)農(nóng)林學(xué)院 信息工程學(xué)院，河南 信陽(yáng) 464000)

0 引言

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

圖1 客戶機(jī)/服務(wù)器系統(tǒng)架構(gòu)

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

圖2 消息在WebSphere MQ中的路由過(guò)程

1 基于交易內(nèi)容的消息路由方法

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

圖3 基于中間件的三層體系結(jié)構(gòu)

1.1 高級(jí)消息隊(duì)列協(xié)議通信實(shí)現(xiàn)過(guò)程

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

圖4 高級(jí)消息隊(duì)列協(xié)議模型層通信實(shí)現(xiàn)過(guò)程

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

1.2 基于交易內(nèi)容的消息路由方法

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

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

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

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

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

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

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

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

2 實(shí)驗(yàn)結(jié)果與性能分析

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

基金開(kāi)戶性能測(cè)試的過(guò)程中，平均事務(wù)響應(yīng)時(shí)間如圖8所示。在平均每秒開(kāi)戶185筆時(shí)，消息中間件和交易中間件的CPU使用率在1%～8%之間，內(nèi)存使用率在2%～7%之間。

圖8 在60個(gè)投資者并發(fā)開(kāi)戶情況下平均事務(wù)響應(yīng)時(shí)間

基金申購(gòu)性能測(cè)試的過(guò)程中，平均事務(wù)響應(yīng)時(shí)間如圖9所示。在已有680萬(wàn)賬戶存量，平均每秒申購(gòu)交易267筆情況下，消息中間件和交易中間件的CPU使用率在1%～8%之間，它們的內(nèi)存使用率在2%～7%之間。

圖9 在60個(gè)投資者并發(fā)申購(gòu)情況下平均事務(wù)響應(yīng)時(shí)間

基金贖回性能測(cè)試的過(guò)程中，平均事務(wù)響應(yīng)時(shí)間如圖10所示。平均每秒發(fā)起307筆贖回交易，系統(tǒng)消息中間件和交易中間件的CPU使用率在1%～8%之間，內(nèi)存使用率也在1%～8%之間。

圖10 在60個(gè)投資者并發(fā)贖回情況下平均事務(wù)響應(yīng)時(shí)間

3 結(jié)論

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

[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的異步通信實(shí)現(xiàn)及其在OpenStack項(xiàng)目中的應(yīng)用[J].軟件導(dǎo)刊，2013, 12(7)：35-37.

[9] 楊萍，李杰. 利用LoadRunner實(shí)現(xiàn)Web負(fù)載測(cè)試的自動(dòng)化[J].計(jì)算機(jī)技術(shù)與發(fā)展，2007, 17(1): 242-244.

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