基于消息隊列的前置系統(tǒng)數(shù)據(jù)庫同步轉(zhuǎn)異步方案設(shè)計

付霞

(上海杉達(dá)學(xué)院，信息學(xué)院， 上海 201209)

0 引言

目前我國的金融系統(tǒng)領(lǐng)域電子化趨勢領(lǐng)跑全球，支付電子化已深入到我們老百姓日常生活的方方面面，可以說，我們的日常生活已經(jīng)離不開電子化的支付方式了，因此支付領(lǐng)域的安全與高可用已經(jīng)上升到國家安全層面了，每個金融機(jī)構(gòu)在監(jiān)管的要求下，都在不遺余力的提升自己系統(tǒng)的安全性與穩(wěn)定性[1]，確保系統(tǒng)的高可用。同時，面對日趨激烈的市場競爭環(huán)境，各金融機(jī)構(gòu)還需要確保自己系統(tǒng)的客戶體驗要好，以免造成客戶的流失。因此，各機(jī)構(gòu)電子銀行渠道針對客戶開放的渠道也是越來越多，就拿普通的城商行來說，目前至少存在以下渠道[2]：微信、支付寶、銀聯(lián)、客服、電話銀行、手機(jī)銀行、網(wǎng)上銀行、柜面、ATM、短信。同時，金融機(jī)構(gòu)內(nèi)部還存在類似核心系統(tǒng)、客戶管理系統(tǒng)、審批系統(tǒng)、授信系統(tǒng)、差錯調(diào)賬系統(tǒng)等等各類功能性系統(tǒng)，這些系統(tǒng)往往都是獨立的子系統(tǒng)，各系統(tǒng)需要與前端渠道進(jìn)行交互，同時各系統(tǒng)之間又存在互相調(diào)用的情況。而為了保證各系統(tǒng)核心部分功能的獨立性，往往都會建設(shè)一套獨立的前置系統(tǒng)(FES)，該系統(tǒng)主要負(fù)責(zé)報文的路由控制、通訊協(xié)議轉(zhuǎn)換、報文格式轉(zhuǎn)換、事務(wù)一致性控制、分對總接入、密鑰等安全管理等[3-4]。該系統(tǒng)作為各系統(tǒng)的入口，控制著各系統(tǒng)的流量，因此該系統(tǒng)的健壯性及高可用對于金融機(jī)構(gòu)的業(yè)務(wù)開展至關(guān)重要。

1 現(xiàn)狀分析

1.1 FES常見架構(gòu)說明

如圖1所示，渠道端對接客戶或內(nèi)部工作人員，將不同的業(yè)務(wù)轉(zhuǎn)成不同的聯(lián)機(jī)交易發(fā)送至FES的不同通信模塊，通常FES支持的通信方式有TCP長連接(單雙工)、TCP短連接、HTTP(S)、MQ等[4]，通信模塊將接收到的完整報文發(fā)送至路由模塊的消息隊列[5-6]；路由模塊根據(jù)不同的業(yè)務(wù)類型將報文轉(zhuǎn)發(fā)至不同的業(yè)務(wù)處理模塊所對應(yīng)的消息隊列中；各業(yè)務(wù)模塊完成相應(yīng)的業(yè)務(wù)邏輯處理后，將報文發(fā)送至對應(yīng)核心系統(tǒng)的通信模塊的消息隊列中，通信模塊負(fù)責(zé)將報文送至對應(yīng)的核心業(yè)務(wù)系統(tǒng)，完成請求報文的整個鏈路。核心業(yè)務(wù)系統(tǒng)處理完請求報文后，通常會有響應(yīng)報文返回，而且響應(yīng)報文一般需要按照原路進(jìn)行返回如圖2所示。

圖1 FCS常見架構(gòu)

其中FES各進(jìn)程之間通過消息隊列進(jìn)行信息交互，業(yè)務(wù)處理模塊需要跟數(shù)據(jù)庫進(jìn)行交互。

1.2 FES的數(shù)據(jù)庫交互操作說明

FES的功能主要是路由控制、通信協(xié)議轉(zhuǎn)換、報文格式轉(zhuǎn)換、事務(wù)一致性控制、分對總接入、密鑰管理。因為基本沒有業(yè)務(wù)數(shù)據(jù)需要保存，那么FES使用數(shù)據(jù)庫的主要目的是為了滿足其中的路由控制和事務(wù)一致性控制功能需要。

以其中的路由控制為例，因為要確保交易的原路返回，所以在接收到請求報文時需要將請求的信息先記錄到數(shù)據(jù)庫中(需要進(jìn)行insert和update操作)，響應(yīng)報文回來時，需要通過查詢數(shù)據(jù)庫來匹配到原請求報文(需要select操作)，進(jìn)而找到響應(yīng)報文的返回路由信息進(jìn)行原路返回，如圖2所示。

圖2 交易鏈路及數(shù)據(jù)庫交互

1.3 FES的雪崩效應(yīng)產(chǎn)生原因分析

雪崩效應(yīng)[7]通常指的是：起初只是一個小小的擾動，但是事態(tài)發(fā)展越來越嚴(yán)重，往往成幾何級數(shù)增長。而對于一個IT系統(tǒng)來說，當(dāng)一筆業(yè)務(wù)所經(jīng)過的鏈路中出現(xiàn)A資源等待時，會造成該筆業(yè)務(wù)耗時過長，同時后續(xù)業(yè)務(wù)因此出現(xiàn)排隊等待現(xiàn)象，因后續(xù)業(yè)務(wù)也需要占用其他的系統(tǒng)資源如B、C等，進(jìn)而造成B、C資源的不足，最終導(dǎo)致整個系統(tǒng)各模塊均不可用，這就是IT系統(tǒng)的雪崩效應(yīng)。

而FES的運(yùn)行需要依賴硬件、操作系統(tǒng)平臺及數(shù)據(jù)庫，一般來說，因為硬件可以根據(jù)需要進(jìn)行升級，操作系統(tǒng)一般不會是IT系統(tǒng)的瓶頸，所以對于FES來說，數(shù)據(jù)庫往往是瓶頸所在，也是雪崩效應(yīng)產(chǎn)生的根源(對于某些業(yè)務(wù)，可能會使用到加密機(jī)，加密機(jī)往往也是瓶頸所在，本文不討論對于加密機(jī)訪問瓶頸的優(yōu)化)。

如圖3所示，當(dāng)數(shù)據(jù)庫響應(yīng)慢的時候，路由模塊還會持續(xù)不斷往消息隊列B發(fā)送報文，如果消息隊列B被堵滿的話，路由模塊則無法繼續(xù)工作；進(jìn)而導(dǎo)致消息隊列A的報文無法處理，這又會導(dǎo)致消息隊列A被堵滿；進(jìn)而導(dǎo)致通信模塊無法繼續(xù)工作，通信模塊如果是短連接的話，因為報文沒能及時返回，進(jìn)而導(dǎo)致連接池資源很快被占滿，這個時候整個FES將無法對外提供服務(wù)，產(chǎn)生雪崩效應(yīng)。

圖3 FES雪崩效應(yīng)圖

2 原因分析及解決方案探討

2.1 同步與異步機(jī)制

通過上面的說明可以看出，F(xiàn)ES系統(tǒng)之所以會產(chǎn)生瓶頸及雪崩效應(yīng)，主要在于鏈路上存在資源依賴，尤其是數(shù)據(jù)庫資源,而一旦數(shù)據(jù)庫資源得不到滿足，整個鏈路都被迫處于等待。這時我們把數(shù)據(jù)庫與應(yīng)用之間的交互機(jī)制稱為同步機(jī)制。

同步就相當(dāng)于是當(dāng)客戶端發(fā)送請求給服務(wù)端，在等待服務(wù)端響應(yīng)的請求時，客戶端不做其他的事情。異步就是當(dāng)客戶端發(fā)送給服務(wù)端請求時，在等待服務(wù)端響應(yīng)的時候，客戶端可以做其他的事情。

如果FES的數(shù)據(jù)庫訪問能夠?qū)⑼綑C(jī)制轉(zhuǎn)換為異步機(jī)制[8]，那么就可以解決FES目前碰到的問題了。

2.2 同步轉(zhuǎn)異步的2個問題

要解決FES的同步轉(zhuǎn)異步的問題，需要解決以下2個問題。

(1) 業(yè)務(wù)數(shù)據(jù)的低敏

同步轉(zhuǎn)異步以后，那么也就意味著原業(yè)務(wù)在數(shù)據(jù)庫操作可能失敗的情況下會繼續(xù)進(jìn)行，也就是要保證這些業(yè)務(wù)數(shù)據(jù)丟失也不會對業(yè)務(wù)造成賬務(wù)上的影響。而FES系統(tǒng)因為是轉(zhuǎn)接系統(tǒng)，不直接保留業(yè)務(wù)數(shù)據(jù)，所以，即使是insert或commit失敗，也僅僅是應(yīng)答報文回來后，select不到原交易而無法正常返回，丟失一筆交易。而金融IT系統(tǒng)對此類異常情況都會有對賬與調(diào)賬機(jī)制相配套，因此FES對于業(yè)務(wù)數(shù)據(jù)來說是屬于低敏的。

(2) 緩存機(jī)制

同步要轉(zhuǎn)異步，那么必須要有緩存機(jī)制，在數(shù)據(jù)庫響應(yīng)慢時將所有的數(shù)據(jù)庫操作先緩存起來。比較簡單輕量化的緩存機(jī)制可以采用Linux操作系統(tǒng)提供的消息隊列。

2.3 大型數(shù)據(jù)庫與內(nèi)存數(shù)據(jù)庫的雙數(shù)據(jù)庫設(shè)計

雖然通過緩存機(jī)制解決了偶爾數(shù)據(jù)庫響應(yīng)慢的情況，但是還存在更極端的情況如數(shù)據(jù)庫長時間響應(yīng)慢或者不可用的話，這時也會導(dǎo)致應(yīng)用與數(shù)據(jù)庫之間設(shè)立的緩存空間被占滿，進(jìn)而導(dǎo)致系統(tǒng)完全不可用狀態(tài)，所以，如果能夠使用雙數(shù)據(jù)庫來進(jìn)行熱備的話，則可進(jìn)一步提高系統(tǒng)的健壯性和高可用性。

3 數(shù)據(jù)庫同步轉(zhuǎn)異步的實現(xiàn)方案說明

3.1 數(shù)據(jù)庫同步轉(zhuǎn)異步架構(gòu)說明

原FES業(yè)務(wù)處理模塊與數(shù)據(jù)庫之間交互是通過數(shù)據(jù)庫本身提供的API進(jìn)行交互。新的架構(gòu)里面，F(xiàn)ES業(yè)務(wù)處理模塊將根據(jù)新增的數(shù)據(jù)庫管理模塊設(shè)計提供的API進(jìn)行報文組裝，并且將組裝好的報文發(fā)送到消息隊列，不直接與數(shù)據(jù)庫管理模塊進(jìn)行通信。數(shù)據(jù)庫管理模塊通過從消息隊列獲取需要處理的報文，并優(yōu)先將數(shù)據(jù)庫請求發(fā)往主數(shù)據(jù)庫進(jìn)行處理。如果數(shù)據(jù)庫管理模塊判斷當(dāng)前主數(shù)據(jù)庫狀態(tài)異常，則后續(xù)將數(shù)據(jù)庫請求發(fā)往備數(shù)據(jù)庫。數(shù)據(jù)庫管理模塊根據(jù)設(shè)定的時間對狀態(tài)異常的主數(shù)據(jù)庫再次進(jìn)行判定。其中主數(shù)據(jù)庫一般使用比較大型的商用數(shù)據(jù)庫軟件，如Oracle、DB2、Informix等。備數(shù)據(jù)庫一般采用開源免費的內(nèi)存數(shù)據(jù)庫，如SQLite[9]等。備數(shù)據(jù)庫一般是在主數(shù)據(jù)庫狀態(tài)異常時才會暫時接管數(shù)據(jù)庫請求。對于響應(yīng)報文回來的select操作，一般也是優(yōu)先到主數(shù)據(jù)庫中進(jìn)行查詢，如果搜索不到則到備數(shù)據(jù)庫中再次進(jìn)行查詢。

3.2 雙數(shù)據(jù)庫下的數(shù)據(jù)庫連接池說明

為了提高業(yè)務(wù)處理能力，數(shù)據(jù)庫管理模塊會根據(jù)業(yè)務(wù)量動態(tài)地對直接與數(shù)據(jù)庫進(jìn)行交互的進(jìn)程DBAP的數(shù)量進(jìn)行管理(見圖4)，每個DBAP都會采用競爭模式從同一個消息隊列里面獲取報文并與數(shù)據(jù)庫進(jìn)行交互后，將獲得的數(shù)據(jù)庫返回信息按照約定的API進(jìn)行報文組裝，并發(fā)送到指定的消息隊列中。每個DBAP都具有與雙數(shù)據(jù)庫進(jìn)行通信的能力，所以將這些DBAP的組合稱為雙數(shù)據(jù)庫下的數(shù)據(jù)庫連接池。

圖4 數(shù)據(jù)庫同步轉(zhuǎn)異步的設(shè)計架構(gòu)圖

4 總結(jié)

本文主要介紹了金融系統(tǒng)中非常常見的一種IT系統(tǒng)前置系統(tǒng)的常見架構(gòu)模式，基于該架構(gòu)模式下，又說明了數(shù)據(jù)庫訪問性能瓶頸會導(dǎo)致的整個系統(tǒng)的雪崩效應(yīng)是如何產(chǎn)生的，為了解決這種性能瓶頸與雪崩效應(yīng)現(xiàn)象，分析了原因并指出通過將數(shù)據(jù)庫的訪問模式從同步轉(zhuǎn)成異步即可，而為了對數(shù)據(jù)庫進(jìn)行同步轉(zhuǎn)異步，又說明了必須具備的前提條件，最后，提出了解決方案并對解決方案進(jìn)行了詳細(xì)闡述。同時，本解決方案所提出的問題解決思路在前置類系統(tǒng)中很多需要調(diào)用外部資源的場景下都有較好的通用性，如加密機(jī)資源瓶頸等。