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

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

0 引言

在互聯(lián)網(wǎng)環(huán)境下，應(yīng)用系統(tǒng)總會(huì)面對由于客戶量爆炸式的增長而帶來的系統(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)。

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

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

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

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

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

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

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

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

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

文獻(xiàn)[11]基于傳輸層 UDP,在消息中間件應(yīng)用層設(shè)計(jì)了一種基于否定確認(rèn)(Negative ACKnowl-edgment,NACK) 策略,在消息接收方通過檢測報(bào)文丟失、亂序并提供消息重傳機(jī)制,保證傳輸?shù)目煽啃浴２煌δ軉卧捎秒p工熱備實(shí)現(xiàn)節(jié)點(diǎn)可靠性。

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

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

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

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

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

本文的主要工作:

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

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

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

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

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

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

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

圖1 一般的客戶注冊

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

圖2 基于消息的客戶注冊

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

圖6 消息監(jiān)控

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

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

public List queryConsumer();

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

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

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

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

//發(fā)送補(bǔ)償

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

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

2.4.1 tag設(shè)計(jì)

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

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

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

1)生產(chǎn)者消費(fèi)者消息實(shí)體。

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

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

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

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

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

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

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

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

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

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

2.5 實(shí)驗(yàn)和性能分析

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

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

圖7 RPC和消息通信對比

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

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

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

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

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

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

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

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

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

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

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

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

3 實(shí)例應(yīng)用

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

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

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

圖9 消息吞吐量

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

圖10 督查結(jié)果

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

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

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

4 結(jié)語

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

)

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

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

[3] 王成良. 基于JMS的分布式事務(wù)處理系統(tǒng)的研究與實(shí)現(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ù)總線消息補(bǔ)償方法的設(shè)計(jì)[J]. 微型機(jī)與應(yīng)用, 2013, 32(10):90-91.(SUNHY.Designofmessagecompensationmethodbasedonenterpriseservicebus[J].Microcomputer&ItsApplications, 2013, 32(10): 90-91.)

[6] 邊耐政, 劉玄. 基于非阻塞的分布式事務(wù)提交協(xié)議的實(shí)現(xiàn)[J]. 計(jì)算機(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è)計(jì)與實(shí)現(xiàn)[J]. 計(jì)算機(jī)工程與科學(xué), 2015, 36(2):301-305.(KOUCK,HUS,CHENHY,etal.DesignandimplementationofasubscriptionsysteminATCsystem[J].ComputerEngineeringandScience, 2015, 36(2): 301-305.)

[8] 熊風(fēng)光, 韓燮, 韓焱. 自動(dòng)測試系統(tǒng)消息中間件的設(shè)計(jì)與實(shí)現(xiàn)[J]. 計(jì)算機(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]. 工礦自動(dòng)化, 2013, 39(1):23-26.(LIUP.Applicationofmessageorientedmiddlewaretechnologyincoalminecommunicationsystem[J].IndustryandAutomation, 2013, 39(1): 23-26.)

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

[11] 王重楠, 王宗陶, 鮑忠貴, 等. 發(fā)布/訂閱模式測控消息中間件系統(tǒng)設(shè)計(jì)[J]. 計(jì)算機(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ì)方案[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é)報(bào), 2012, 23(5):1148-1165.(LINZY,LAIYX,LINC,etal.Researchonclouddatabases[J].JournalofSoftware, 2012, 23(5): 1148-1165.)

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

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

[17] 杜岳峰, 申德榮, 聶鐵錚.基于關(guān)聯(lián)數(shù)據(jù)的一致性和時(shí)效性清洗方法[J]. 計(jì)算機(jī)學(xué)報(bào), 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]. 計(jì)算機(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òng)可靠性的一種方法[D]. 蘭州:蘭州大學(xué), 2011:13(MACW.AmethodtoimprovethereliabilityofMINIX3blockdevicedriver[D].Lanzhou:LanzhouUniversity, 2011:13.)

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

[22] 林闖, 陳瑩, 黃霽崴.服務(wù)計(jì)算中服務(wù)質(zhì)量的多目標(biāo)優(yōu)化模型與求解研究[J]. 計(jì)算機(jī)學(xué)報(bào), 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會(huì)員,主要研究方向:分布式系統(tǒng)、大數(shù)據(jù); 黃勃(1985—),男,湖北武漢人,講師,博士,CCF會(huì)員,主要研究方向:人工智能、軟件工程; 馮炯(1974—),男,上海人,高級工程師,碩士,主要研究方向:自然語言處理。

1001- 9081(2017)04- 1157- 07

10.11772/j.issn.1001- 9081.2017.04.1157

TP311.52

A