徐 進(jìn),黃 勃,馮 炯

1.上海你我貸互聯(lián)網(wǎng)金融信息服務(wù)有限公司 技術(shù)中心, 上海 200120; 2.上海工程技術(shù)大學(xué) 電子電氣工程學(xué)院, 上海 201620)(*通信作者電子郵箱xu_zh_h@163.com)

基于消息通信的分布式系統(tǒng)最終一致性平臺

徐 進(jìn)1*,黃 勃2,馮 炯1

1.上海你我貸互聯(lián)網(wǎng)金融信息服務(wù)有限公司 技術(shù)中心, 上海 200120; 2.上海工程技術(shù)大學(xué) 電子電氣工程學(xué)院, 上海 201620)(*通信作者電子郵箱xu_zh_h@163.com)

在分布式系統(tǒng)中為了滿足高性能和吞吐量,一般采用異步消息通信方式，但消息通信沒有解決分布式事務(wù)不一致問題。針對這個問題,提出建立一致性保障平臺,通過這個平臺實現(xiàn)最終一致性。首先,使系統(tǒng)滿足冪等性以及業(yè)務(wù)數(shù)據(jù)與消息生產(chǎn)消費記錄強一致性;其次,建立消息監(jiān)控機制,根據(jù)監(jiān)控規(guī)則和消費生產(chǎn)消費記錄,判定消息正常還是需要補償操作或者冪等操作,從而保證分布式系統(tǒng)基于消息通信的最終一致;最后,在整個設(shè)計實現(xiàn)過程中采用關(guān)注點分離和橫向切分的思想與工程化的方法,實現(xiàn)一致性保障平臺。通過實驗和分析證明比較得出，與異步消息通信相比，分布式消息通信性能更優(yōu)越； 一致性保障平臺能及時發(fā)現(xiàn)不一致并由系統(tǒng)及時處理,實現(xiàn)最終一致,即可以完全保障系統(tǒng)最終一致性；而且該平臺通過平臺化的實現(xiàn)方式在應(yīng)用中可以快速復(fù)用到數(shù)十個業(yè)務(wù)系統(tǒng)。由此得出一致性保障平臺可以解決分布式交易系統(tǒng)事務(wù)最終一致性問題,不僅性能優(yōu)越而且經(jīng)濟。

分布式;消息通信;消息中間件;一致性;冪等;事務(wù);體系結(jié)構(gòu)設(shè)計

0 引言

在互聯(lián)網(wǎng)環(huán)境下，應(yīng)用系統(tǒng)總會面對由于客戶量爆炸式的增長而帶來的系統(tǒng)壓力，為了緩解系統(tǒng)壓力目前普遍采用分布式系統(tǒng)架構(gòu)，而進(jìn)程間通信是分布式系統(tǒng)的核心技術(shù),目前廣泛采用的進(jìn)程間通信模式有: 遠(yuǎn)程過程調(diào)用(Remote Procedure Call, RPC)、遠(yuǎn)程方法調(diào)用(Remote Method Invoke, RMI)、消息中間件(Message-Oriented Middleware,MOM)[1]以及流(stream)。

消息傳遞機制可以避免通信阻塞,增加系統(tǒng)的吞吐量,以及解耦不同系統(tǒng)直接交互,在不需要請求立即返回結(jié)果的場景下，這些特性帶來了明顯的通信優(yōu)勢。消息中間件的體系結(jié)構(gòu)由消息生產(chǎn)者、消息中間件、消息消費者三個部分組成,消息的生產(chǎn)者和消息的消費者只和消息中間件交互,生產(chǎn)者和消費者不直接交互。

消息中間件的使用過程是,當(dāng)業(yè)務(wù)系統(tǒng)業(yè)務(wù)成功后,創(chuàng)建消息,然后向消息中間件發(fā)送消息,消息中間件接收到消息并存儲消息;當(dāng)消息中間件存在未被消費的消息時,消息中間件向消費消息的業(yè)務(wù)系統(tǒng)推送消息。

從消息中間件使用過程看：一方面消息發(fā)送和消息消費通過網(wǎng)絡(luò)交互,網(wǎng)絡(luò)不穩(wěn)定會導(dǎo)致消息丟失或者重復(fù)；另一方面消息中間件消息推送機制不是實時的,極端情況下會出現(xiàn)幾天甚至幾十天延遲,這也會導(dǎo)致消息不一致。在使用消息中間件系統(tǒng)時，首先需要解決消息生產(chǎn)者和消息中間件之間以及消息中間件和消息消費者之間消息的一致性問題。這個一致性包括:1)消息發(fā)送一致性,即消息生產(chǎn)者業(yè)務(wù)成功發(fā)送消息到消息中間件,消息中間件也能成功收到消息,發(fā)送消息時網(wǎng)絡(luò)出現(xiàn)問題或者消息中間件不可用,則消息丟失;2)消息消費一致性,即消息消費者只成功消費一次消息,當(dāng)消息消費者成功消費消息后,向消息中間件發(fā)送確認(rèn)消息時網(wǎng)絡(luò)故障或者消息中間件不可用,會導(dǎo)致消息消費者重復(fù)消費消息。

目前對消息中間件已經(jīng)有很多研究文獻(xiàn),文獻(xiàn)[2]討論了采用統(tǒng)一消息隊列中間件軟總線實現(xiàn)電力調(diào)度自動化系統(tǒng),設(shè)計和實現(xiàn)了多個應(yīng)用子系統(tǒng)的集成,但是并沒有給出多個系統(tǒng)間消息一致性的解決方案,這樣不能滿足分布式交易系統(tǒng)應(yīng)用。

文獻(xiàn)[3]指出傳統(tǒng)二階段提交不適合分布式復(fù)雜網(wǎng)絡(luò)環(huán)境,“為了避免提交子事務(wù)等待時間過長,而造成事務(wù)阻塞和對系統(tǒng)資源的浪費”,把二階段提交改成一階段提交；但也指出一階段提交是基于“全局事務(wù)最終能夠正常提交的樂觀想法上的”。文獻(xiàn)指出傳統(tǒng)二階段分布式事務(wù)性能缺陷,并通過采用消息機制解決一致性問題,但存在兩個問題:1)不是所有場景都能改成消息機制來解決一致性；2)改成消息機制后,如何保障消息本身的一致性[4]。

文獻(xiàn)[5]中采用補償?shù)姆椒▽崿F(xiàn)事務(wù),保證系統(tǒng)一致。其主要思想是當(dāng)出現(xiàn)異常時,會觸發(fā)針對異常的一個回滾事件,使系統(tǒng)恢復(fù)到執(zhí)行前狀態(tài),不會由于異常導(dǎo)致系統(tǒng)不一致；但文獻(xiàn)中沒有考慮網(wǎng)絡(luò)異常情況,沒有加入冪等機制和不一致檢查機制,無法滿足分布式交易系統(tǒng)一致性要求。

文獻(xiàn)[6]較完整地分析了二階段提交和三階段提交保證分布式事務(wù)一致性帶來的性能損耗,采用非阻塞方式會提升性能；但沒有考慮異常情況怎么處理,無法滿足事務(wù)的一致性。

文獻(xiàn)[7-9]都指出了通過消息訂閱/發(fā)布可實現(xiàn)松散耦合的、靈活的跨平臺的通信機制的系統(tǒng),比傳統(tǒng)的通信機制有更多的優(yōu)點。

文獻(xiàn)[10]指出消息中間件應(yīng)用時,遇到網(wǎng)絡(luò)環(huán)境不穩(wěn)定,通過設(shè)計一個鏈路檢測系統(tǒng)盡早發(fā)現(xiàn)網(wǎng)絡(luò)問題,但對于網(wǎng)絡(luò)問題導(dǎo)致的系統(tǒng)不一致,并沒有給出方案。

文獻(xiàn)[11]基于傳輸層 UDP,在消息中間件應(yīng)用層設(shè)計了一種基于否定確認(rèn)(Negative ACKnowl-edgment,NACK) 策略,在消息接收方通過檢測報文丟失、亂序并提供消息重傳機制,保證傳輸?shù)目煽啃?。不同功能單元采用雙工熱備實現(xiàn)節(jié)點可靠性。

文獻(xiàn)[12]采用“Quorum-Based算法”與消息區(qū)域模型相結(jié)合的方法保證分布式消息中間件的數(shù)據(jù)一致性。其作用是保證多個消費節(jié)點狀態(tài)一致,其一致性類型屬于最終一致性。

在文獻(xiàn)[4，13-14]中給出了分布式系統(tǒng)設(shè)計的總體原則,根據(jù)CAP(Consistency,Availability,Partition tolerance)理論[15],一個分布式系統(tǒng)不可能同時滿足一致性、可用性和分區(qū)容錯性這三個特性,最多只能同時滿足兩個。尤其在文獻(xiàn)[13]中,提出了BASE(Basically Available,Soft state,Eventually consistent)思想,通過犧牲高一致性, 保證高可用性和分區(qū)容忍性,這有很強的實踐指導(dǎo)意義,即分布式系統(tǒng)和傳統(tǒng)系統(tǒng)有很大區(qū)別，以及系統(tǒng)設(shè)計時要懂得取舍。

在文獻(xiàn)[16-17]中對分布式系統(tǒng)中數(shù)據(jù)一致性檢測,并且考慮了大數(shù)據(jù)的數(shù)據(jù)遷移以及檢測的時效性,但沒有考慮分布式交易環(huán)境下一致性的檢測和一致性保障。

針對上述相關(guān)研究,總結(jié)如下:1)在分布式場景中肯定了消息中間件可以解耦交互的系統(tǒng),提高系統(tǒng)的吞吐量的作用；2)在保障分布式系統(tǒng)一致性上從多個方面進(jìn)行了關(guān)注；3)對分布式系統(tǒng)的設(shè)計給出了CAP原則；4)關(guān)注了事務(wù)補償機制在分布式事務(wù)中保持最終一致性的作用。

在現(xiàn)有的研究中還存在以下問題:1)沒有認(rèn)真分析不同的分布式應(yīng)用場景,并且針對不同場景給出不同的一致性解決方案,兩階段提交措施不適合高并發(fā)場景；2)缺少最終一致性完整的解決方案,分布式交易系統(tǒng)的一致性需要考慮多個方面,譬如性能、可靠性,從不一致的檢測到實現(xiàn)一致性的多個環(huán)節(jié)；3)沒有指出產(chǎn)生不一致消息的時機，具體的時機可能是消息生產(chǎn)時、消息傳遞時、消息消費時,造成不一致的原因可能是網(wǎng)絡(luò)異常造成的,可能是消息中間件延遲造成的,或者可能是生產(chǎn)端接收端異常造成消息和業(yè)務(wù)的不一致,對問題認(rèn)識越深刻才能找到好的解決辦法。

本文的主要工作:

1)在分布式交易環(huán)境下,提出如何采用消息通信方式來保障分布式系統(tǒng)間數(shù)據(jù)的最終一致性的完整方法,包括：采用本地事務(wù)記錄消息生產(chǎn)和消費,采用后臺進(jìn)程比較數(shù)據(jù)發(fā)現(xiàn)異常,采用冪等機制滿足異常重試,采用補償措施進(jìn)行異常回滾。通過這些方法形成分布式交易系統(tǒng)最終一致性完整解決方案。

2)對消息通信方式和RPC通信方式的性能進(jìn)行對比分析實驗,指出了在分布式高并發(fā)環(huán)境中消息通信方式性能上具有優(yōu)勢。

3)采用軟件工程化的方法進(jìn)行關(guān)注點分離,把一致性保障措施設(shè)計為一個平臺,有利于軟件復(fù)用,提高經(jīng)濟效益。

1 一致性保障層體系結(jié)構(gòu)設(shè)計

分布式系統(tǒng)雖然有高性能的優(yōu)點,但同時也帶來了問題,如一致性降低等問題,在交易系統(tǒng)中不允許存在不一致。為了揭示這個問題,先從一個分布式應(yīng)用場景入手分析導(dǎo)致不一致的原因,然后給出解決不一致的方法機制,最后設(shè)計出對應(yīng)的軟件體系結(jié)構(gòu)。

1.1 消息通信的分布式系統(tǒng)應(yīng)用場景分析

一個常見的場景是客戶在網(wǎng)站注冊,注冊成功則向這個用戶送積分和現(xiàn)金抵用券,最后再短信通知客戶,采用序列圖[18]表示注冊過程，如圖1所示。注冊、送積分、發(fā)短信和送抵用券分屬不同系統(tǒng),系統(tǒng)之間通信采用同步方式或者異步方式。注冊過程則不依賴其他三個過程。

圖1 一般的客戶注冊

在互聯(lián)網(wǎng)應(yīng)用環(huán)境中,客戶注冊是個高并發(fā)應(yīng)用場景，為了滿足并發(fā)要求會把這個業(yè)務(wù)拆分成多個子業(yè)務(wù)分別實現(xiàn)在不同的系統(tǒng)中，形成分布式系統(tǒng)。在高并發(fā)環(huán)境下,分布式系統(tǒng)一般采用異步的消息機制作為系統(tǒng)間的通信方式,通過消息中間件解耦[19]注冊和其他三個過程,解耦可以提高注冊的并發(fā)度,消息中間件適合異步通信場景,改進(jìn)后如圖2所示。注冊作為消息生產(chǎn)者,其他三個過程作為消息消費者,如果不做其他工作,在消息的生產(chǎn)和消費過程中不能保證一致,會給用戶帶來不好的體驗。

圖2 基于消息的客戶注冊

1.2 一致性保障機制設(shè)計

從圖2可以抽象出這樣的分布式系統(tǒng)通信是由消息提供者、消息消費者、消息中間件和網(wǎng)絡(luò)組成。根據(jù)消息服務(wù)器特性在下列情況下會出現(xiàn)消息生產(chǎn)者和消息消費者不一致情況:

1)消費者成功從消息服務(wù)器消費消息,當(dāng)發(fā)送消費成功回執(zhí)給消息服務(wù)器時,網(wǎng)絡(luò)出現(xiàn)異常,服務(wù)器沒有收到回執(zhí),則這條消息消費者還可以再消費,會導(dǎo)致消費者重復(fù)消費消息現(xiàn)象。

2)當(dāng)生產(chǎn)者成功創(chuàng)建消息時,網(wǎng)絡(luò)出現(xiàn)異常,導(dǎo)致消息沒有發(fā)送到消息服務(wù)器,會導(dǎo)致消息丟失現(xiàn)象。

3)當(dāng)消息生產(chǎn)者的生產(chǎn)消息過程和對應(yīng)的業(yè)務(wù)不在一個事務(wù)中,相對生產(chǎn)者業(yè)務(wù)會出現(xiàn)產(chǎn)生多余消息或者丟失消息現(xiàn)象。

4)當(dāng)消息消費者的消費消息過程和對應(yīng)的業(yè)務(wù)不在一個事務(wù)中,相對消費業(yè)務(wù)會也會出現(xiàn)消息丟失或者消息重復(fù)消費現(xiàn)象。

5)當(dāng)消息服務(wù)器出現(xiàn)異常時,會出現(xiàn)消息丟失現(xiàn)象。

從上述現(xiàn)象中,可以總結(jié)出三類問題,本地事務(wù)和消息不一致、網(wǎng)絡(luò)和服務(wù)器異常、消費者重復(fù)消費?？梢酝ㄟ^如下的機制解決上述問題,通過消息消費者的冪等性,解決消息重復(fù)消費問題,具體實現(xiàn)方式是:

1)通過為每個業(yè)務(wù)類型的業(yè)務(wù)單據(jù)設(shè)計唯一編號并通過該編號關(guān)聯(lián)消費記錄，實現(xiàn)對消息消費的感知。當(dāng)消費者消費消息時,先比較該消息所對應(yīng)的業(yè)務(wù)編號是否消費過,如果消費過則不觸發(fā)業(yè)務(wù)但向消息服務(wù)器返回消費成功標(biāo)識,如果沒有消費過則消費該消息。

2)通過本地事務(wù)解決生產(chǎn)者和消費者的業(yè)務(wù)與消息的一致性問題。具體實現(xiàn)就是當(dāng)對應(yīng)業(yè)務(wù)成功時,在本地數(shù)據(jù)庫中記錄消息的生產(chǎn)和消費。

3)通過一個后臺監(jiān)控機制實現(xiàn)網(wǎng)絡(luò)異常和消息服務(wù)器異常導(dǎo)致的消息不一致問題。具體實現(xiàn)就是通過比較數(shù)據(jù)庫的記錄,發(fā)現(xiàn)不一致消息,并對不一致消息作相應(yīng)的處理。

1.3 一致性體保障平臺系結(jié)構(gòu)設(shè)計

1.3.1 總體體系結(jié)構(gòu)設(shè)計

從基于消息通信的分布式系統(tǒng)看,一致性保障層處于業(yè)務(wù)應(yīng)用系統(tǒng)和消息中間件之間,實現(xiàn)業(yè)務(wù)系統(tǒng)消息通信的最終一致性；從一致性實現(xiàn)機制看,一致性體保障層的系結(jié)構(gòu)主要組成:消息生產(chǎn)者、消息消費者、消息監(jiān)控、消息冪等處理、消息查詢、保障層后臺管理,見圖3。

圖3 一致性保障平臺體系結(jié)構(gòu)

消息生產(chǎn)者記錄和業(yè)務(wù)一致的消息生產(chǎn)記錄,消息消費者記錄和業(yè)務(wù)一致的消費記錄,保障層后臺管理用于配置數(shù)據(jù)源、消息監(jiān)視規(guī)則、控制規(guī)則和其他系統(tǒng)配置,消息查詢用于查詢消息生產(chǎn)消費狀態(tài)。

消息冪等處理:為了提升系統(tǒng)性能,通過分布式緩存服務(wù)器記錄每個應(yīng)用已經(jīng)消費的消息對應(yīng)的業(yè)務(wù)唯一編號,設(shè)置15天前的消息持久化到硬盤,保證有足夠的物理內(nèi)存存儲這些唯一業(yè)務(wù)編號,當(dāng)有業(yè)務(wù)編號請求,如果在緩存中能查到則不用再消費,如果沒有查到,則消費消息,并保存消息。采用緩存服務(wù)器記錄業(yè)務(wù)編號的好處有兩點：一是性能提升；二是把比較功能從業(yè)務(wù)代碼中分離到框架層。

消息監(jiān)控:在后臺啟動一個監(jiān)控進(jìn)程,遍歷消息生產(chǎn)消費記錄,按照監(jiān)控規(guī)則,如果在一定時間消費端沒有出現(xiàn)已經(jīng)生產(chǎn)的消息,則可能是消息丟失或者消息延遲,按照控制規(guī)則,可以再生成相同的消息讓消費者消費。

更復(fù)雜的監(jiān)控情況是,當(dāng)分布式交互的各方如果有一個執(zhí)行失敗,其他的各方都要停止執(zhí)行和回滾已經(jīng)執(zhí)行的結(jié)果,消費者接收到消息,發(fā)起業(yè)務(wù)處理,當(dāng)業(yè)務(wù)處理失敗時,消費者把業(yè)務(wù)處理失敗狀態(tài)寫入到對應(yīng)的消息,當(dāng)監(jiān)控到消費者的業(yè)務(wù)處理狀態(tài)是失敗時,按照監(jiān)控規(guī)則發(fā)起對應(yīng)的補償操作,撤銷消息生產(chǎn)者的業(yè)務(wù)操作和其他消費者的業(yè)務(wù)操作,即進(jìn)行事務(wù)的補償操作。

1.3.2 消息監(jiān)控模塊體系結(jié)構(gòu)設(shè)計

消息監(jiān)控部件是整個一致性保障平臺的核心,包含了復(fù)雜的邏輯,從軟件設(shè)計目標(biāo)可擴展、可復(fù)用和易讀方面來看,采用多維視角的橫切思想,并且采用正交的軟件體系結(jié)構(gòu)對消息監(jiān)控進(jìn)行設(shè)計,如圖4。系統(tǒng)初始化是在系統(tǒng)啟動時根據(jù)系統(tǒng)配置啟動對應(yīng)的消息監(jiān)控進(jìn)程;消息監(jiān)控是監(jiān)控進(jìn)程讀取到消息生產(chǎn)和消費記錄及其狀態(tài),再根據(jù)每種消息的監(jiān)控規(guī)則進(jìn)行確認(rèn)完成、消息重發(fā)和消息補償。

圖4 消息監(jiān)控組件體系結(jié)構(gòu)

2 一致性保障層關(guān)鍵功能設(shè)計和實現(xiàn)

根據(jù)前面的分析關(guān)鍵點有:通過本地事務(wù)實現(xiàn)生產(chǎn)者和消費者保障消息記錄和業(yè)務(wù)一致性,消費者冪等處理,消息監(jiān)控機制。本章將從以上幾點分別進(jìn)行描述。

2.1 生產(chǎn)者創(chuàng)建消息設(shè)計實現(xiàn)

分布式系統(tǒng)在很多情況下都會出現(xiàn)不一致，而且也無法避免這些情況的發(fā)生，但是如果能把所有通信和事件都記錄下來，那么就能感知到系統(tǒng)出現(xiàn)不一致，所以通過本地事務(wù)，在事務(wù)中同時記錄業(yè)務(wù)發(fā)生數(shù)據(jù)和消息發(fā)送備案數(shù)據(jù)，就能保證業(yè)務(wù)數(shù)據(jù)和消息發(fā)送備案數(shù)據(jù)強一致。

通過圖5,可以知道消息生產(chǎn)消費過程的一個概貌,這些實體之間的關(guān)系,通過本地事物實現(xiàn)業(yè)務(wù)和消息數(shù)據(jù)一致,如果消息發(fā)送失敗,在后續(xù)的消息監(jiān)控中可以發(fā)現(xiàn)并進(jìn)行消息重發(fā),確保該消息一定發(fā)送成功。

圖5 消息生產(chǎn)過程

代碼注意要點是兩個保存(保存業(yè)務(wù)信息與保存消息內(nèi)容)在一個事務(wù),而且發(fā)送消息必須有異常處理,并且由單獨的線程處理,這樣即使發(fā)送消息出現(xiàn)網(wǎng)絡(luò)延遲或者異常都不會影響業(yè)務(wù)實現(xiàn),沒有發(fā)送成功的消息平臺的監(jiān)控進(jìn)程會在后臺主動重試發(fā)送,具體實現(xiàn)代碼如下:

public void bizService(){ saveBizData();

//保存業(yè)務(wù)數(shù)據(jù) saveMegData();

//保存消息數(shù)據(jù) try { SendMegThread sendMegThread=new SendMegThread(); sendMegThread.start();

//新起線程發(fā)送消息

} catch (Exception e) {

// TODO Auto-generated catch block e.printStackTrace();

}

}

2.2 消息監(jiān)控設(shè)計實現(xiàn)

消息監(jiān)控是一致性保障的核心模塊，該模塊包含了監(jiān)視規(guī)則和控制規(guī)則。首先啟動兩個進(jìn)程分別監(jiān)控生產(chǎn)端和消費端,然后按照規(guī)則,如果匹配成功則標(biāo)識為監(jiān)控結(jié)束,如果出現(xiàn)異常則發(fā)送補償消息,如果丟失或者延遲則發(fā)送重試消息。主要監(jiān)控流程如圖6,為了簡單明了圖中省略了多個消費者。

圖6 消息監(jiān)控

采用spring3定時框架啟動后臺監(jiān)控進(jìn)程,具體配置:

在定時任務(wù)線程中調(diào)用監(jiān)控功能,功能接口如下:

public List queryConsumer();

//查詢待匹配消費消息 public List queryProduc-er();

//查詢待匹配生產(chǎn)者消息 public void matchMeg(List listConsumerMeg,List listProduc-erMeg);

//匹配生產(chǎn)者和消費者消息 public void sendRetryMeg(ProducerMeg producerMeg);

//發(fā)送重試 public void sendEqualizeMeg(ConsumerMeg consumerMeg);

//發(fā)送補償

2.3 冪等處理設(shè)計和實現(xiàn)

由于消息通信方式,消息傳遞也是通過網(wǎng)絡(luò)實現(xiàn),如果出現(xiàn)網(wǎng)絡(luò)異常需要容錯機制,消費者從消息服務(wù)器獲取消息,并成功消費,當(dāng)反饋成功狀態(tài)給消息服務(wù)器時出現(xiàn)網(wǎng)絡(luò)異常,則消息服務(wù)器還會繼續(xù)保留此消息,消費者還能繼續(xù)消費該消息,為了保證消費者不重復(fù)消費,采用緩存服務(wù)器作為冪等[20]處理機制。具體實現(xiàn)采用redis作為緩存集群服務(wù)器,由集群層框架提供一致性性Hash和負(fù)載均衡策略,在客戶端通過jedis框架訪問緩存,系統(tǒng)初始化時創(chuàng)建連接池,提升系統(tǒng)性能,采用map數(shù)據(jù)結(jié)構(gòu)存儲唯一業(yè)務(wù)編碼,代碼中需要注意使用連接池,并且使用完需立即返回連接池。其主要代碼如下:

public static boolean existsKey(String key){ Boolean value= false; JedisPool pool=null; Jedis jedis=null; try { pool=getPool(); jedis= pool.getResource(); value= jedis. exists(key);

} catch (Exception e) {

//釋放redis對象 pool.returnBrokenResource(jedis); e.printStackTrace();

} finally {

//返還到連接池 returnResource(pool, jedis);

}

return value;

}

2.4 數(shù)據(jù)設(shè)計

2.4.1 tag設(shè)計

在消息中間件中消息由消息主題topic、消息標(biāo)簽tag和消息內(nèi)容組成,topic規(guī)定消息在消息中間件中的哪個隊列存儲,消息內(nèi)容與該條消息關(guān)聯(lián)的業(yè)務(wù)相關(guān),這兩個單元的內(nèi)容都是客觀的,不能隨意改變。通過設(shè)計tag的組成,可以賦予消息更多的內(nèi)涵,使消息中間件同時為多個業(yè)務(wù)使用,并且保證每條消息唯一性和時效性,具體見表1。數(shù)據(jù)對象為tag。

2.4.2 數(shù)據(jù)庫設(shè)計

數(shù)據(jù)庫設(shè)計[21]的出發(fā)點是系統(tǒng)要實現(xiàn)的功能和目標(biāo),在前面已經(jīng)詳細(xì)分析了系統(tǒng)的目標(biāo)和要實現(xiàn)的功能,根據(jù)數(shù)據(jù)庫設(shè)計的方法,確定數(shù)據(jù)實體有:生產(chǎn)者消息實體、消費者消息實體、督查結(jié)果消息實體和配置所包含的一組實體。

1)生產(chǎn)者消費者消息實體。

表示哪個業(yè)務(wù)系統(tǒng)的哪個節(jié)點什么時間產(chǎn)生了一條什么樣的消息,或者哪個系統(tǒng)的節(jié)點消費了一條消息,以及該消息什么時候被某個對象消費,為了節(jié)省存儲空間,沒有記錄消息內(nèi)容。見表1,生產(chǎn)者內(nèi)容由九個屬性組成(即表1中第一列的內(nèi)容為tag和生產(chǎn)者的九行),消費者的內(nèi)容也由九個屬性組成(即表1中第一列的內(nèi)容為tag和消費者的九行)。

2)后臺檢查結(jié)果。

后臺進(jìn)程獲取上面的生產(chǎn)者和消費者數(shù)據(jù),通過全局唯一標(biāo)識關(guān)聯(lián)數(shù)據(jù),再通過匹配規(guī)則,可以得到如下結(jié)果:生產(chǎn)消費正常;生產(chǎn)和消費不一致但還沒有觸發(fā)異常處理;消費延遲或者消息丟失,需要重試發(fā)起消息;消費者處理出現(xiàn)異常,對應(yīng)的操作需要回滾。這些操作和狀態(tài)通過表1中tag和檢查數(shù)據(jù)對象的屬性集合記錄下來。

業(yè)務(wù)系統(tǒng)編號:用于標(biāo)識每條消息是屬于哪個業(yè)務(wù)系統(tǒng),由封裝的客戶端從配置文件獲取,對使用消息中間件的業(yè)務(wù)系統(tǒng)透明。

主機編號:標(biāo)識這條消息是集群中哪臺機器發(fā)出的,由封裝的客戶端從配置文件獲取,對使用消息中間件的業(yè)務(wù)系統(tǒng)透明。

業(yè)務(wù)類型:標(biāo)識屬于哪個業(yè)務(wù)。

時間戳:標(biāo)識這條消息的創(chuàng)建時間,由消息中間件客戶端在發(fā)送時產(chǎn)生,對使用消息中間件的業(yè)務(wù)系統(tǒng)透明。

業(yè)務(wù)編號:由使用消息中間件的業(yè)務(wù)系統(tǒng)傳送，可以通過這個內(nèi)容追溯到具體業(yè)務(wù)。

消息內(nèi)容:記錄該消息的內(nèi)容。

表1 數(shù)據(jù)對象設(shè)計

2.5 實驗和性能分析

從前面的分析中可知,上面的設(shè)計相比傳統(tǒng)消息系統(tǒng)增加了兩個記錄過程,這個記錄過程可能會對性能帶來損耗,從測試來看,在雙核CPU,內(nèi)存為6 GB，操作系統(tǒng)是SUSI Linux, MySQL版本是5.6.15,采用單條插入的方式,每行只有10個字段的情況下,每秒大約2 000條數(shù)據(jù),這也就是其性能極限。在實際應(yīng)用中單業(yè)務(wù)系統(tǒng)業(yè)務(wù)量很難達(dá)到這個極限，即使達(dá)到極限也可以通過批量插入提升上限，所以對性能的損耗可以忽略。

從并發(fā)性角度再對比分布式系統(tǒng)采用RPC通信方式和消息通信方式對整個分布式系統(tǒng)性能和吞吐量的影響,如圖7所示,表示一個總?cè)蝿?wù)分別調(diào)用三個子任務(wù),每個子任務(wù)又分別使用數(shù)據(jù)庫資源,協(xié)同完成總?cè)蝿?wù)。

圖7 RPC和消息通信對比

為了比較RPC通信方式和消息通信方式效率，假定一個事物，需要多個子系統(tǒng)協(xié)作完成的場景，需要分別表示任務(wù)、資源、任務(wù)對資源的占用、任務(wù)執(zhí)行的時間，具體表示如下：

任務(wù)集合T={T1,T2,…,Tn};

資源集合R={R1,R2,…,Rm}。

任務(wù)使用的資源關(guān)系表示每個任務(wù)可能使用的任意個資源：

TR{{R1,R2,…,Rm},…,{R1,R2,…,Rn}}

一個進(jìn)程需要引用的子任務(wù)Process{T1T2…Tk}(k

下面分別計算兩種通信方式完成一個總?cè)蝿?wù)需要的時間和資源的最大吞吐量。整個服務(wù)完成時間=計算時間+I/O時間+網(wǎng)絡(luò)時間+資源等待時間。為了方便計算,把和通信效率無關(guān)的耗時都忽略掉,例如把占時比例極小的計算時間和I/O時間忽略,同時考慮到可能發(fā)生的資源沖突導(dǎo)致等待時間，如果在RPC同步通信方式下該時間會被累計，而在消息通信方式下不會累計，即該因素對RPC通信方式的影響更大，為了比較它們優(yōu)劣也可以忽略掉,僅僅保留網(wǎng)絡(luò)通信時間。假設(shè)每次網(wǎng)絡(luò)通信時間為time：

RPC通信方式任務(wù)完成時間為PTRPC=2×Pm×time(Pm為協(xié)調(diào)的子任務(wù)，每個任務(wù)耗時2×time，即請求時間+應(yīng)答時間);

消息通信方式時間為PTMSG=time+2×time。

在并發(fā)場景中資源的限制往往成了系統(tǒng)的瓶頸，對資源占用的耗時越小，系統(tǒng)的吞吐量就越大，P1表示一個具體事務(wù)，對應(yīng)的子任務(wù)集合{T1，T2,…,Tm}，這些子任務(wù)使用的資源集合R1是{R1，R2,…，Rn},在一個事物中都是開始事務(wù)時分配所有資源，直到事務(wù)結(jié)束才收回資源，結(jié)合這個原理，再分析一個事務(wù)在不同通信方式下的資源占用時間,RPC通信方式資源集合R1的占用時間是任務(wù)執(zhí)行時間是PTRPC消息通信方式資源占用時間是PTMSG

從上面分析可知,RPC通信方式任務(wù)執(zhí)行時間隨著參與方增加而增加,而消息通信方式不會;對資源占用時間，RPC方式會隨著參與方增加而增加,但消息通信方式不會。

通過以上分析可知消息通信的效率更高，而且資源占用時間更短，在高并發(fā)場景下不易發(fā)生資源沖突，在實際運行中服務(wù)質(zhì)量度量是對多個指標(biāo)進(jìn)行建模[22],不同進(jìn)程之間是相互影響的一個動態(tài)過程,例如本例中,由于運行時間加長會導(dǎo)致資源鎖定時間增加,資源鎖定時間增加會降低系統(tǒng)吞吐量,從而降低了系統(tǒng)提供服務(wù)的能力。

3 實例應(yīng)用

該平臺和其他相關(guān)系統(tǒng)部署見圖8,包括數(shù)據(jù)服務(wù)器、消息集群服務(wù)器、緩存集群服務(wù)器等,在這種部署下為實現(xiàn)整個平臺高可用和高性能提供基礎(chǔ)設(shè)施保障。

圖8 一致性保障平臺部署圖

在實際應(yīng)用中,消息中間件服務(wù)器采用雙核CPU、8GB內(nèi)存,操作系統(tǒng)是Centos6.5,消息中間件同時為風(fēng)控系統(tǒng)、財務(wù)系統(tǒng)、網(wǎng)站系統(tǒng)、移動系統(tǒng)提供消息服務(wù)。圖9為對應(yīng)系統(tǒng)在10min內(nèi)各時刻的消息吞吐量。從圖9中可以看到,按照每分鐘采集各系統(tǒng)的消息處理量,最上面的曲線反映網(wǎng)站系統(tǒng)消息吞吐量,約每分鐘2 000條,財務(wù)系統(tǒng)吞吐量最小。

圖9 消息吞吐量

消息督查是通過定時任務(wù)發(fā)現(xiàn)消息丟失和消息重復(fù),見圖10,該圖描述了每條消息在生產(chǎn)端、消息中間件和消費端的狀態(tài),從狀態(tài)可知該消息是否發(fā)生異常。對于出現(xiàn)異常的消息可以人工處理或者通過補償措施自動處理,從而保證系統(tǒng)最后一致。例如客戶注冊成功,當(dāng)發(fā)送通知消息和發(fā)送優(yōu)惠券重復(fù),根據(jù)系統(tǒng)設(shè)置,出現(xiàn)異常消息在3s之內(nèi)即通知,這時如果通知消息沒有發(fā)送則可以取消發(fā)送,贈送的優(yōu)惠券可以沖紅處理;當(dāng)注冊成功,但是消息中間件沒有收到,那么根據(jù)系統(tǒng)設(shè)置30s即報告異常,這時通過人工處理或者補償操作即可保持系統(tǒng)一致。

圖10 督查結(jié)果

在實際應(yīng)用中一致性保障平臺在保障分布式系統(tǒng)一致性方面發(fā)揮了巨大作用,表2中的狀態(tài)補償指逆向操作,從數(shù)據(jù)上看,每天發(fā)生的每一次通信都能被平臺捕獲,并且對其狀態(tài)進(jìn)行跟蹤,即時糾正了不一致數(shù)據(jù)。如果未采用這個平臺,數(shù)據(jù)不一致發(fā)生后需要在日終對賬后才能修正,可見一致性保障平臺是分布式交易系統(tǒng)的核心組件。

表2 消息狀態(tài)日跟蹤

從應(yīng)用來看,通過緩存系統(tǒng)和異步消息通信提升系統(tǒng)性能,通過部署高可用集群提供高可用性,通過一致性保障平臺提供一致性。

4 結(jié)語

本文設(shè)計實現(xiàn)了在分布式交易環(huán)境中保障系統(tǒng)最終一致性的平臺,該平臺通過本地事務(wù)、補償機制和冪等性,在滿足系統(tǒng)性能的前提下實現(xiàn)可以保障在分布式系統(tǒng)中事務(wù)的最終一致性。該平臺實現(xiàn)過程中考慮了軟件工程化思想采用復(fù)用思想抽象為可擴展的平臺,提升了平臺的經(jīng)濟價值。通過實驗和分析可知該平臺具有高性能,并且采用高可用集群,從實際應(yīng)用來看,為業(yè)務(wù)軟件快速開發(fā)提供技術(shù)保障，在實際應(yīng)用中發(fā)揮了強大的作用,創(chuàng)造了很大的價值。

)

[1] 王偉卿, 孫莉. 基于Java消息服務(wù)的消息中間件的應(yīng)用研究[J]. 計算機技術(shù)與發(fā)展, 2009, 19(7):220-222.(WANGWQ,SUNL.Applicationandresearchofmessage-orientedmiddlewarebasedonJMS[J].ComputerTechnologyandDevelopment, 2009, 19(7): 220-222.)

[2] 陳榕, 陳廉青, 謝巧云, 等. 消息隊列中間件在電力調(diào)度通信軟件上的應(yīng)用[J]. 計算機工程, 2004, 30(19):148-150.(CHENR,CHENLQ,XIEQY,etal.ApplicationofmessagequeuemiddlewareintheSCADA/EMS[J].ComputerEngineering, 2004, 30(19): 148-150.)

[3] 王成良. 基于JMS的分布式事務(wù)處理系統(tǒng)的研究與實現(xiàn)[D]. 鄭州:信息工程大學(xué), 2010:16-36.(WANGCL.ResearchandimplementationofdistributedtransactionsystembasedonJMS[D].Zhengzhou:PLAInformationEngineeringUniversity, 2010:16-36.)

[4]TANENBAUMAS,VANSTEENM. 分布式系統(tǒng)原理與泛型[M]. 辛春生, 陳宗斌, 譯.2版.北京:清華大學(xué)出版社, 2008:200-230.(TANENBAUMAS,VANSTEENM.DistributedSystem:PrinciplesandParadigms[M].XINCS,CHENZB,translated. 2ed.Beijing:TsinghuaUniversityPress, 2008: 200-230.)

[5] 孫赫勇. 基于企業(yè)服務(wù)總線消息補償方法的設(shè)計[J]. 微型機與應(yīng)用, 2013, 32(10):90-91.(SUNHY.Designofmessagecompensationmethodbasedonenterpriseservicebus[J].Microcomputer&ItsApplications, 2013, 32(10): 90-91.)

[6] 邊耐政, 劉玄. 基于非阻塞的分布式事務(wù)提交協(xié)議的實現(xiàn)[J]. 計算機應(yīng)用與軟件, 2014, 31(7):89-92.(BIANLZ,LIUX.Implementationofnon-blockingbaseddistributedtransactioncommitprotocol[J].ComputerApplicationsandSoftware, 2014, 31(7): 89-92.)

[7] 寇成坤, 胡術(shù), 陳虹宇, 等.ATC系統(tǒng)中發(fā)布訂閱系統(tǒng)的設(shè)計與實現(xiàn)[J]. 計算機工程與科學(xué), 2015, 36(2):301-305.(KOUCK,HUS,CHENHY,etal.DesignandimplementationofasubscriptionsysteminATCsystem[J].ComputerEngineeringandScience, 2015, 36(2): 301-305.)

[8] 熊風(fēng)光, 韓燮, 韓焱. 自動測試系統(tǒng)消息中間件的設(shè)計與實現(xiàn)[J]. 計算機應(yīng)用與軟件, 2013, 30(4):65-68.(XIONGFG,HANX,HANY.Designandimplementationofmessage-orientedmiddlewareforautomatictestsystem[J].ComputerApplicationsandSoftware, 2013, 30(4): 65-68.)

[9] 劉鵬. 消息中間件技術(shù)在煤礦井下通信系統(tǒng)中的應(yīng)用[J]. 工礦自動化, 2013, 39(1):23-26.(LIUP.Applicationofmessageorientedmiddlewaretechnologyincoalminecommunicationsystem[J].IndustryandAutomation, 2013, 39(1): 23-26.)

[10] 姜夢蘭. 基于消息中間件服務(wù)可靠性保障方案的研究與實現(xiàn)[D]. 成都:電子科技大學(xué), 2010:28-52.(JIANGML.Researchandimplementationofservicereliabilityassuranceschemebasedonmessageorientedmiddleware[D].Chengdu:UniversityofElectronicScienceandTechnologyofChina, 2010:28-52.)

[11] 王重楠, 王宗陶, 鮑忠貴, 等. 發(fā)布/訂閱模式測控消息中間件系統(tǒng)設(shè)計[J]. 計算機應(yīng)用, 2015, 35(3):878-881.(WANGCN,WANGZT,BAOZG,etal.Designoftelemetryandcommandmessage-orientedmiddlewaresystemwithpublish/subscribemodel[J].JournalofComputerApplications, 2015, 35(3): 878-881.)

[12] 史耀政, 庫流亨.一種分布式SCADA消息中間件設(shè)計方案[J]. 測控技術(shù)與儀器儀表, 2016, 42(3):84-86.(SHIYZ,KULH.AdesignschemeofdistributedmessageorientedmiddlewareforSCADA[J].MeasurementControlTechnologyandInstrumentation, 2016, 42(3): 84-86.)

[13] 李馮筱, 羅高松.NoSQL理論體系及應(yīng)用[J]. 電信科學(xué), 2012(12):23-30.(LIFX,LUOGS.StudyonNoSQLtheoryanddatabase[J].TelecommunicationScience, 2012(12): 23-30.)

[14] 林子雨, 賴永炫, 林琛, 等. 云數(shù)據(jù)庫研究[J]. 軟件學(xué)報, 2012, 23(5):1148-1165.(LINZY,LAIYX,LINC,etal.Researchonclouddatabases[J].JournalofSoftware, 2012, 23(5): 1148-1165.)

[15] 陳明. 分布系統(tǒng)設(shè)計的CAP理論[J]. 計算機教育, 2013(15):109-112.(CHENM.CAPtheoryfordistributedsystemdesign[J].ComputerEducation, 2013(15): 109-112.)

[16] 李衛(wèi)榜, 李戰(zhàn)懷, 陳群, 分布式大數(shù)據(jù)不一致性檢測[J]. 軟件學(xué)報, 2016, 27(8):2068-2085.(LIWB,LIZH,CHENQ.Inconsistencydetectionindistributedbigdata[J].JournalofSoftware, 2016, 27(8): 2068-2085.)

[17] 杜岳峰, 申德榮, 聶鐵錚.基于關(guān)聯(lián)數(shù)據(jù)的一致性和時效性清洗方法[J]. 計算機學(xué)報, 2017, 40(1):92-105.(DUYF,SHENDR,NIETZ.Acleaningmethodforconsistencyandcurrencyinrelateddata[J].ChineseJournalofComputers, 2017, 40(1):92-105.)

[18]JOHNWS,ROBERTBJ,STEPHENDB.SystemsAnalysisandDesigninaChangingWorld[M].Beijing:ChinaMachinePress, 2001:228.

[19] 徐晶, 許煒. 消息中間件綜述[J]. 計算機工程, 2005, 31(16):73-76.(XUJ,XUW.Summarizationofmessage-orientedmiddleware[J].ComputerEngineering, 2005, 31(16): 73-76.)

[20] 馬長旺. 提高M(jìn)INIX3塊設(shè)備驅(qū)動可靠性的一種方法[D]. 蘭州:蘭州大學(xué), 2011:13(MACW.AmethodtoimprovethereliabilityofMINIX3blockdevicedriver[D].Lanzhou:LanzhouUniversity, 2011:13.)

[21]STEPHENSRK,PLEWRR.PLEW數(shù)據(jù)庫設(shè)計[M]. 何玉清, 武欣, 鄧一凡, 等譯. 北京:機械工業(yè)出版社, 2001:14-19.(STEPHENSRK,PLEWRR.PLEWDatabaseDesign[M].HEYQ,WUX,DENGYF,etal.translated.Beijing:ChinaMachinePress, 2001:14-19.)

[22] 林闖, 陳瑩, 黃霽崴.服務(wù)計算中服務(wù)質(zhì)量的多目標(biāo)優(yōu)化模型與求解研究[J]. 計算機學(xué)報, 2015, 38(10):1907-1923.(LINC,CHENY,HUANGJW.Asurveyonmodelsandsolutionsofmulti-objectiveoptimizationforQoSinservicescomputing[J].ChineseJournalofComputers, 2015, 38(10): 1907-1923.)

XU Jin, born in 1976, M. S., senior engineer. His research interests include distributed system, big data.

HUANG Bo, born in 1985, Ph. D., lecturer. His research interests include artificial intelligence, software engineering.

FENG Jiong, born in 1974, M. S., senior engineer. His research interests include natural language processing.

Eventual consistency platform of distributed system based on message communication

XU Jin1*, HUANG Bo2, FENG Jiong1

(1. Technology Center, Shanghai Niwodai Internet Financial Information Service Company Limited, Shanghai 200120, China;2. School of Electronic and Electrical Engineering, Shanghai University of Engineering Science, Shanghai 201620,China)

In order to meet the performance and throughput requirements of distributed systems, the asynchronous message communication is a common strategy. However, this strategy can not solve the consistency problem of the distributed system. In order to solve this problem, this paper proposed the establishment of consistency guarantee platform. Firstly, the system fulfilled idempotency and strong consistency between business data and message production/consumption records. Secondly, a message monitoring strategy was established. And it could be decided whether a message was correct or the compensation/idempotent operation was needed, according to the monitoring rules and production/consumption records, in order to realize the eventual consistency of the distributed system based on message communication. Lastly, the Separation of Concerns (SoC) and horizontal segmentation methods were adopted in design and realization of this platform. Experiments and analyses have shown the better performance of this distributed message communication, comparing to the asynchronous communication. This platform could timely check and handle the inconsistency and thus achieve the eventual consistency, i.e. the final eventual consistency of the whole system. Also the platform design could easily be adopted to multiply business systems, which means this platform is not only superior-performed but also economic.

distributed; message communication; message oriented middleware; consistency; idempotency; transaction; architecture design

2016- 08- 30;

2016- 12- 28。

徐進(jìn)(1976—),男,安徽合肥人,高級工程師,碩士,CCF會員,主要研究方向:分布式系統(tǒng)、大數(shù)據(jù); 黃勃(1985—),男,湖北武漢人,講師,博士,CCF會員,主要研究方向:人工智能、軟件工程; 馮炯(1974—),男,上海人,高級工程師,碩士,主要研究方向:自然語言處理。

1001- 9081(2017)04- 1157- 07

10.11772/j.issn.1001- 9081.2017.04.1157

TP311.52

A