分佈式事務產生的原因
- 數據庫分庫分表
- 微服務化
- 在微服務架構中，每個服務在用本地事務的時候，知道自己執行的事務是成功還是失敗，但是無法知道其他服務節點的事務執行情況，因此需要引入協調者TM，負責協調參與者RM的行為，並最終決定這些參與者是否把事務進行提交。
隨著微服務架構的流行，讓分佈式事務問題日益突出， 那麼常見的分佈式事務解決方案有哪些呢？ 如何理解最終一致性和它的事務補償機制呢？
剛性事務 - 強一致性
image.png
如上圖，這是個標準的全局事務，事務管理器控制著全局事務，管理事務的生命週期，並通過XA協議與資源管理器協調資源；資源管理器負責控制和管理實際的資源 （這裡的資源管理器，可以是一個DBMS，或者消息服務管理系統）
兩階段提交
它是XA用於在全局事務中協調多個資源的機制，常用於事務管理器和資源管理器之間，解決一致性問題，分兩階段：
- 提交事務請求
- 執行事務請求
image.png
2PC的問題
- 效率低，與本地事務相比，XA協議的系統開銷比較大（數據被鎖定的時間跨度整個事務，直到全局事務的結束），只有支持XA協議的資源才能參與分佈式事務。
- 2PC是反可伸縮模式的，在事務處理過程中，參與者需要一直持有資源直到整個事務的結束，這樣當業務規模越來越大的情況下，它的侷限性就越明顯。
- 數據不一致，在2pc中的第二階段時，當TM向RM發送提交請求之後，發生局部的網絡異常或者在發送提交請求過程中TM發生故障， 這會導致只有一部分RM收到了提交請求，然後沒有收到提交請求的RM不會執行事務的提交，於是整個分佈式系統便會出現數據不一致。
- 單點故障， 由於TM的重要性，一旦發生故障，整個事務失效
3PC的改進
增加了超時機制， 主要解決單點故障問題，並減少資源鎖定時間，一旦RM無法及時收到來至TM的信息之後，它會默認執行Commit操作， 而不會一直持有事務資源並處於阻塞狀態。但是這種機制同樣會導致數據不一致的問題，由於網絡的原因，TM發送的回滾動作，沒有被RM及時的收到，那麼RM等待超時後就執行了提交操作，這樣就和收到回滾操作並執行的RM之間存在了數據不一致的情況。
柔性事務 - 最終一致性
在2008年，eBay公佈了基於BASE準則的最終一致性解決方案，它主要採用了消息隊列來輔助實現事務控制流程，其核心通過消息隊列的方式來異步執行分佈式處理的任務，如果事務失敗，則可以發起人工重試的糾正流程（比如對賬系統，對處於dead letter queue的問題進行處理）
消息發送一致性
微服務架構下，需要通過網絡進行通信，就自然引入了數據傳輸的不確定性，也就是CAP原理中的P-分區容錯，而這裡的消息發送一致性是可靠消息的保證。
生成消息的業務動作與消息發送的一致（e.g： 如果業務操作成功，那麼由這個業務操作所產生的消息一定會成功投遞出去，否則就丟失消息）
最終一致性.png
如上圖，保證消息發送一致性的一般流程如下：
- Producer先把消息發送給消息中間件服務，消息的狀態標記為待確認，這個狀態並不會被Consumer消費，對於長期待確認的消息，消息中間件會調用Producer的查詢接口，查看最新狀態，根據結果決定是否刪除消息。
- Producer執行完業務操作後，向消息中間件服務，發送確認消息
- 這時消息的狀態會被更改為待發送（可發送）
- Consumer監聽並接收待發送狀態的消息，執行業務處理
- Consumer業務處理後，向消息中間件服務發送ACK，確認消息已經收到（消息中間件服務將從隊列中刪除該消息）
消息的ACK確認流程中，任何一個環節都可能會出問題！
對未ACK的消息，採用按規則重新投遞的方式進行處理（很多MQ都提供at least once的投遞，持久化和重試機制），一般還會設置重發的次數， 超過次數的消息會進入dead letter queue，等待人工干預或者延後定時處理。
業務接口的冪等性
消息的重複發送會導致業務接口出現重複調用的問題，主要原因就是消息沒有及時收到ACK確認導致的， 那如何實現冪等性設計呢？
在實際的業務場景中， 業務接口的冪等性設計，常結合查詢操作一起使用，
比如根據唯一標識查詢消息是否被處理過， 或者根據消費日誌表，來維護消息消費的記錄。
保證最終一致性的模式
- 可查詢模式，任何一個服務操作都提供一個可查詢接口，用來向外部輸出操作執行的狀態，下游Consumer可以通過接口得知服務操作執行的狀態，然後根據不同的狀態做不同的處理操作（執行或者取消）， 該模式對業務接口有一定侵入性。
- 補償模式， 有了查詢模式，我們能夠知道操作的具體狀態，如果處於不正常狀態，我們可以修正操作中出現的問題，或許是重新執行，或許取消已經完成的操作，通過修復是的整個分佈式系統達到最終一致。
- 最大努力通知模式， 在調用支付寶交易接口或微信支付接口時，一般會在回調頁面和接口裡，解密參數，然後調用系統中更新交易狀態相關的服務，將訂單更新為付款成功。同時，只有當回調頁面中輸出了success字樣或者標識業務處理成功相應狀態碼時，支付寶才會停止回調請求。否則，支付寶會每間隔一段時間後，再向客戶方發起回調請求，直到輸出成功標識為止。
閱讀更多 Java全棧技術 的文章
