基于消息通信的分布式系統最終一致性平臺

徐 進,黃 勃,馮 炯

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

基于消息通信的分布式系統最終一致性平臺

徐 進1*,黃 勃2,馮 炯1

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

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

分布式;消息通信;消息中間件;一致性;冪等;事務;體系結構設計

0 引言

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

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

消息中間件的使用過程是,當業務系統業務成功后,創建消息,然后向消息中間件發送消息,消息中間件接收到消息并存儲消息;當消息中間件存在未被消費的消息時,消息中間件向消費消息的業務系統推送消息。

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

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

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

文獻[5]中采用補償的方法實現事務,保證系統一致。其主要思想是當出現異常時,會觸發針對異常的一個回滾事件,使系統恢復到執行前狀態,不會由于異常導致系統不一致；但文獻中沒有考慮網絡異常情況,沒有加入冪等機制和不一致檢查機制,無法滿足分布式交易系統一致性要求。

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

文獻[7-9]都指出了通過消息訂閱/發布可實現松散耦合的、靈活的跨平臺的通信機制的系統,比傳統的通信機制有更多的優點。

文獻[10]指出消息中間件應用時,遇到網絡環境不穩定,通過設計一個鏈路檢測系統盡早發現網絡問題,但對于網絡問題導致的系統不一致,并沒有給出方案。

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

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

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

在文獻[16-17]中對分布式系統中數據一致性檢測,并且考慮了大數據的數據遷移以及檢測的時效性,但沒有考慮分布式交易環境下一致性的檢測和一致性保障。

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

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

本文的主要工作:

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

2)對消息通信方式和RPC通信方式的性能進行對比分析實驗,指出了在分布式高并發環境中消息通信方式性能上具有優勢。

3)采用軟件工程化的方法進行關注點分離,把一致性保障措施設計為一個平臺,有利于軟件復用,提高經濟效益。

1 一致性保障層體系結構設計

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

1.1 消息通信的分布式系統應用場景分析

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

圖1 一般的客戶注冊

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

圖2 基于消息的客戶注冊

1.2 一致性保障機制設計

從圖2可以抽象出這樣的分布式系統通信是由消息提供者、消息消費者、消息中間件和網絡組成。根據消息服務器特性在下列情況下會出現消息生產者和消息消費者不一致情況:

1)消費者成功從消息服務器消費消息,當發送消費成功回執給消息服務器時,網絡出現異常,服務器沒有收到回執,則這條消息消費者還可以再消費,會導致消費者重復消費消息現象。

2)當生產者成功創建消息時,網絡出現異常,導致消息沒有發送到消息服務器,會導致消息丟失現象。

3)當消息生產者的生產消息過程和對應的業務不在一個事務中,相對生產者業務會出現產生多余消息或者丟失消息現象。

4)當消息消費者的消費消息過程和對應的業務不在一個事務中,相對消費業務會也會出現消息丟失或者消息重復消費現象。

5)當消息服務器出現異常時,會出現消息丟失現象。

從上述現象中,可以總結出三類問題,本地事務和消息不一致、網絡和服務器異常、消費者重復消費。可以通過如下的機制解決上述問題,通過消息消費者的冪等性,解決消息重復消費問題,具體實現方式是:

1)通過為每個業務類型的業務單據設計唯一編號并通過該編號關聯消費記錄，實現對消息消費的感知。當消費者消費消息時,先比較該消息所對應的業務編號是否消費過,如果消費過則不觸發業務但向消息服務器返回消費成功標識,如果沒有消費過則消費該消息。

2)通過本地事務解決生產者和消費者的業務與消息的一致性問題。具體實現就是當對應業務成功時,在本地數據庫中記錄消息的生產和消費。

3)通過一個后臺監控機制實現網絡異常和消息服務器異常導致的消息不一致問題。具體實現就是通過比較數據庫的記錄,發現不一致消息,并對不一致消息作相應的處理。

1.3 一致性體保障平臺系結構設計

1.3.1 總體體系結構設計

從基于消息通信的分布式系統看,一致性保障層處于業務應用系統和消息中間件之間,實現業務系統消息通信的最終一致性；從一致性實現機制看,一致性體保障層的系結構主要組成:消息生產者、消息消費者、消息監控、消息冪等處理、消息查詢、保障層后臺管理,見圖3。

圖3 一致性保障平臺體系結構

消息生產者記錄和業務一致的消息生產記錄,消息消費者記錄和業務一致的消費記錄,保障層后臺管理用于配置數據源、消息監視規則、控制規則和其他系統配置,消息查詢用于查詢消息生產消費狀態。

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

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

更復雜的監控情況是,當分布式交互的各方如果有一個執行失敗,其他的各方都要停止執行和回滾已經執行的結果,消費者接收到消息,發起業務處理,當業務處理失敗時,消費者把業務處理失敗狀態寫入到對應的消息,當監控到消費者的業務處理狀態是失敗時,按照監控規則發起對應的補償操作,撤銷消息生產者的業務操作和其他消費者的業務操作,即進行事務的補償操作。

1.3.2 消息監控模塊體系結構設計

消息監控部件是整個一致性保障平臺的核心,包含了復雜的邏輯,從軟件設計目標可擴展、可復用和易讀方面來看,采用多維視角的橫切思想,并且采用正交的軟件體系結構對消息監控進行設計,如圖4。系統初始化是在系統啟動時根據系統配置啟動對應的消息監控進程;消息監控是監控進程讀取到消息生產和消費記錄及其狀態,再根據每種消息的監控規則進行確認完成、消息重發和消息補償。

圖4 消息監控組件體系結構

2 一致性保障層關鍵功能設計和實現

根據前面的分析關鍵點有:通過本地事務實現生產者和消費者保障消息記錄和業務一致性,消費者冪等處理,消息監控機制。本章將從以上幾點分別進行描述。

2.1 生產者創建消息設計實現

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

通過圖5,可以知道消息生產消費過程的一個概貌,這些實體之間的關系,通過本地事物實現業務和消息數據一致,如果消息發送失敗,在后續的消息監控中可以發現并進行消息重發,確保該消息一定發送成功。

圖5 消息生產過程

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

public void bizService(){ saveBizData();

//保存業務數據 saveMegData();

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

//新起線程發送消息

} catch (Exception e) {

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

}

}

2.2 消息監控設計實現

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

圖6 消息監控

采用spring3定時框架啟動后臺監控進程,具體配置:

在定時任務線程中調用監控功能,功能接口如下:

public List queryConsumer();

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

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

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

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

//發送補償

2.3 冪等處理設計和實現

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

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 數據設計

2.4.1 tag設計

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

2.4.2 數據庫設計

數據庫設計[21]的出發點是系統要實現的功能和目標,在前面已經詳細分析了系統的目標和要實現的功能,根據數據庫設計的方法,確定數據實體有:生產者消息實體、消費者消息實體、督查結果消息實體和配置所包含的一組實體。

1)生產者消費者消息實體。

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

2)后臺檢查結果。

后臺進程獲取上面的生產者和消費者數據,通過全局唯一標識關聯數據,再通過匹配規則,可以得到如下結果:生產消費正常;生產和消費不一致但還沒有觸發異常處理;消費延遲或者消息丟失,需要重試發起消息;消費者處理出現異常,對應的操作需要回滾。這些操作和狀態通過表1中tag和檢查數據對象的屬性集合記錄下來。

業務系統編號:用于標識每條消息是屬于哪個業務系統,由封裝的客戶端從配置文件獲取,對使用消息中間件的業務系統透明。

主機編號:標識這條消息是集群中哪臺機器發出的,由封裝的客戶端從配置文件獲取,對使用消息中間件的業務系統透明。

業務類型:標識屬于哪個業務。

時間戳:標識這條消息的創建時間,由消息中間件客戶端在發送時產生,對使用消息中間件的業務系統透明。

業務編號:由使用消息中間件的業務系統傳送，可以通過這個內容追溯到具體業務。

消息內容:記錄該消息的內容。

表1 數據對象設計

2.5 實驗和性能分析

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

從并發性角度再對比分布式系統采用RPC通信方式和消息通信方式對整個分布式系統性能和吞吐量的影響,如圖7所示,表示一個總任務分別調用三個子任務,每個子任務又分別使用數據庫資源,協同完成總任務。

圖7 RPC和消息通信對比

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

任務集合T={T1,T2,…,Tn};

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

任務使用的資源關系表示每個任務可能使用的任意個資源：

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

一個進程需要引用的子任務Process{T1T2…Tk}(k

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

RPC通信方式任務完成時間為PTRPC=2×Pm×time(Pm為協調的子任務，每個任務耗時2×time，即請求時間+應答時間);

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

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

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

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

3 實例應用

該平臺和其他相關系統部署見圖8,包括數據服務器、消息集群服務器、緩存集群服務器等,在這種部署下為實現整個平臺高可用和高性能提供基礎設施保障。

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

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

圖9 消息吞吐量

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

圖10 督查結果

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

表2 消息狀態日跟蹤

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

4 結語

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

)

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

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

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

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

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

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

[7] 寇成坤, 胡術, 陳虹宇, 等.ATC系統中發布訂閱系統的設計與實現[J]. 計算機工程與科學, 2015, 36(2):301-305.(KOUCK,HUS,CHENHY,etal.DesignandimplementationofasubscriptionsysteminATCsystem[J].ComputerEngineeringandScience, 2015, 36(2): 301-305.)

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

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

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

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

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

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

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

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

[16] 李衛榜, 李戰懷, 陳群, 分布式大數據不一致性檢測[J]. 軟件學報, 2016, 27(8):2068-2085.(LIWB,LIZH,CHENQ.Inconsistencydetectionindistributedbigdata[J].JournalofSoftware, 2016, 27(8): 2068-2085.)

[17] 杜岳峰, 申德榮, 聶鐵錚.基于關聯數據的一致性和時效性清洗方法[J]. 計算機學報, 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] 馬長旺. 提高MINIX3塊設備驅動可靠性的一種方法[D]. 蘭州:蘭州大學, 2011:13(MACW.AmethodtoimprovethereliabilityofMINIX3blockdevicedriver[D].Lanzhou:LanzhouUniversity, 2011:13.)

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

[22] 林闖, 陳瑩, 黃霽崴.服務計算中服務質量的多目標優化模型與求解研究[J]. 計算機學報, 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。

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

1001- 9081(2017)04- 1157- 07

10.11772/j.issn.1001- 9081.2017.04.1157

TP311.52

A