微服務的搭建

微服務中我們把業務的能力進行了抽象，實際的業務中我們需要用到不同的服務的能力，並且我們處理的業務需要事務的一致性，避免出現數據的紊亂，那麽我們就需要對分布式的微服務進行一致性事務的處理。下面是我自己總結的幾種方案。

分布式事務解決的方案

一、（XA）兩階段方案

1、先提交每一個（這個是加鎖）

2、確認資源，確認每一個RM是否都成功了，判斷是否要提交還是要回滾

二、TCC（try-confirm-cancle）兩階段補償性方案

1、先提交狀態為中間狀態（數據表更改為更新中，而不是加鎖）

2、確認資源，確認每一個RM是否都成功了，都成功了，更新sql的狀態，否則回滾

TCC相比於XA的優點

1、TCC是更新數據為中間狀態，而兩階段方案是加鎖

2、TCC能夠對分布式事務中的各個資源進行分別鎖定，分別提交與釋放，例如，假設有AB 兩個操作，假設A操作耗時短，那麽A就能較快的完成自身的try-confirm-cancel流程，釋 放資源，無需等待B操作。如果事後出現問題, 追加執行補償性事務即可

3、TCC是綁定在各個子業務上的(除了cancle中的全局回滾操作)，也就是各服務之間可以 在一定程度上”異步並行”執行

適用的場景：

1、嚴格一致性

2、執行時間短

3、實時性要求高

三、異步確認性

通過將一系列同步的事務操作變為基於消息執行異步操作，避免了分布式事務中的同步阻塞 操作的影響。

需要額外說明的一點，就是事務消息投遞到MQ定閱方後，並不一定能夠成功執行。

需要 MQ訂閱方主動給予消費反饋（ack）:

1、如果MQ訂閱方執行遠程事務成功，則給予消費成功的ACK,那麽MQ server可以將事務 消息移除；

2、如果執行失敗，MQ Server需要對消息重新投遞，直至消費成功。

註意事項

1、消息中間件在系統中扮演一個重要的角色，所有的事務消息都需要通過它來傳達，所以 消息中間件也需要支持 HAC 來確保事務消息不丟失。

2、根據業務邏輯的具體實現不同，還可能需要對消息中間件增加消息不重復，不亂序等其 它要求。

適用場景

1、執行周期較長

2、實時行要求不高

例如

1、跨行轉賬/匯款業務（兩個服務分別在不同的銀行中）

2、退貨/退款業務

3、財務，賬單統計業務（先發送到消息中間件，然後進行批量記賬）

四、最大努力通知型

這是分布式事務中要求最低的一種，也可以通過消息中間件實現，與前面異步確保型操作不 同的一點是，在消息由MQ Server投遞到消費者之後，允許在達到最大重試次數之後正常 結束事務。

適用場景

交易結果消息的通知等。

微服務-分布式事務解決方案