在系統服務化的過程中，我們不得不面臨的一個問題是多個子系統間業務資料的一致性如何保證，解決這個問題有多種方式。

XA

可能很多人首先會想到XA規範中定義的分散式事務，下圖是XA規範中定義的DTP(Distributed Transaction Processing)模型：

但該模式並不適用於如今的網際網路應用，主要有以下幾點問題：
1. XA採用2PC，並不能完全保證一致性；
2. 2PC有同步阻塞問題，並且增加了2次RTTs(round trip times)，效能低下；
3. 服務化架構天然與DTP模型相悖，服務化架構顯然是面向服務的，為了解決資料一致性，直接向對方暴露資料庫，這還是服務化嗎？

本地訊息表+MQ

既然分散式事務不行，我們自然想到了本地事務，可以利用本地事務的ACID特性來保證一致性，資料儲存之後，再想辦法將資料傳輸給其它系統，做之後的業務處理，如果處理失敗，還可以重試。這個過程實現起來並不難，並且有多種實現方式，但每個系統自己去搞成本還是很高的，所以我們追求的是一種通用且相對優雅的方式。目前業界多數都採用本地訊息表+MQ的方式，本地訊息表設計成一種通用的結構，與業務模型無關，將其放到業務庫同例項上，這樣就可以保證業務操作和儲存訊息在同一個事物內，其它執行緒讀取訊息表資料，傳送到MQ Server(broker)，傳送成功則刪除資料，失敗則保留資料，後續會不斷重試，直至成功。隨後MQ Server進行廣播通知其它系統，做後續處理，如果處理失敗，MQ Server負責重試。

• 首先，我們要搭建一個公共的MQ Server；
• 其次，我們要預先在業務庫去建立一個訊息表，可以通過運維的手段解決；
• 最後，我們要提供一個拆箱即用的Message Producer API，遮蔽傳送訊息的細節，Message Consumer API直接用MQ原生的即可。

@Transactional
public void doSth(Object obj) {
    xxxDao.insert(obj);// 1.biz operation
    Message msg = buildMessage(obj);
    messageProducer.sendMessage(msg);// 2.store msg
 

}

這套機制從0搭建起來還是需要較大成本的，但搭建完之後將一勞永逸，算是先苦後甜吧。

RocketMQ

那有沒有現成的解決方案呢？答案是有的，那就是今年風頭很盛的RocketMQ（已成為Apache頂級專案），RocketMQ在其商業版中提供了事物型訊息，所謂事物型訊息就是保證了業務操作和傳送訊息滿足一致性（業務操作成功，訊息一定傳送成功，業務操作失敗，訊息一定未傳送，反之也成立），上面描述的方式（本地訊息表+MQ）就可以看作是事物型訊息，下面引用一下阿里中介軟體團隊部落格中的描述。

這裡的事務訊息指的其實是資料傳送者事務訊息，簡單而言就是在真正地做業務邏輯之前會發送一條半訊息到服務端，接下來發送者會執行本地的事務，在完成本地事務之後，如果成功就會向服務端傳送一條確認資訊，這時候服務端會將之前的半訊息事務狀態進行變更；如果失敗了，服務端就會不斷地回撥客戶端，來保證傳送端的事務一致性。

http://jm.taobao.org/2017/03/09/20170309/

這裡的關鍵點是第三步如果失敗，要依靠第四步broker回撥客戶端來保證一致性，這裡猜測一下其大概實現，客戶端傳送訊息前，會新增一個事物檢查的實現，並開通一個埠，broker回撥時會攜帶著topic、message等資訊，客戶端依據message資訊和自己的業務資料判定是提交或者回滾，可能有些業務場景依據這兩個資訊無法判定，那客戶端依然要建立本地訊息表。

其它方案

其它方案大多缺失普適性，比如TCC(Try/Confirm/Cancel)，適用於金融領域。