基于消息隊列的前置系統數據庫同步轉異步方案設計

付霞

(上海杉達學院，信息學院， 上海 201209)

0 引言

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

1 現狀分析

1.1 FES常見架構說明

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

圖1 FCS常見架構

其中FES各進程之間通過消息隊列進行信息交互，業務處理模塊需要跟數據庫進行交互。

1.2 FES的數據庫交互操作說明

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

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

圖2 交易鏈路及數據庫交互

1.3 FES的雪崩效應產生原因分析

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

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

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

圖3 FES雪崩效應圖

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

2.1 同步與異步機制

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

同步就相當于是當客戶端發送請求給服務端，在等待服務端響應的請求時，客戶端不做其他的事情。異步就是當客戶端發送給服務端請求時，在等待服務端響應的時候，客戶端可以做其他的事情。

如果FES的數據庫訪問能夠將同步機制轉換為異步機制[8]，那么就可以解決FES目前碰到的問題了。

2.2 同步轉異步的2個問題

要解決FES的同步轉異步的問題，需要解決以下2個問題。

(1) 業務數據的低敏

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

(2) 緩存機制

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

2.3 大型數據庫與內存數據庫的雙數據庫設計

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

3 數據庫同步轉異步的實現方案說明

3.1 數據庫同步轉異步架構說明

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

3.2 雙數據庫下的數據庫連接池說明

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

圖4 數據庫同步轉異步的設計架構圖

4 總結

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