原創:魔鏡的技術心經
分布式事務產生的原因
隨著微服務架構的流行，讓分布式事務問題日益突出， 那麼常見的分布式事務解決方案有哪些呢？ 如何理解最終一致性和它的事務補償機制呢？
剛性事務 - 強一致性
如上圖，這是個標準的全域性事務，事務管理器控制著全域性事務，管理事務的生命週期，並通過xa協議與資源管理器協調資源；資源管理器負責控制和管理實際的資源 （這裡的資源管理器，可以是乙個dbms，或者訊息服務管理系統）
兩階段提交
它是xa用於在全域性事務中協調多個資源的機制，常用於事務管理器和資源管理器之間，解決一致性問題，分兩階段：
2pc的問題
3pc的改進
增加了超時機制， 主要解決單點故障問題，並減少資源鎖定時間，一旦rm無法及時收到來至tm的資訊之後，它會預設執行commit操作， 而不會一直持有事務資源並處於阻塞狀態。但是這種機制同樣會導致資料不一致的問題，由於網路的原因，tm傳送的回滾動作，沒有被rm及時的收到，那麼rm等待超時後就執行了提交操作，這樣就和收到回滾操作並執行的rm之間存在了資料不一致的情況。
柔性事務 - 最終一致性
在2023年，ebay公布了基於base準則的最終一致性解決方案，它主要採用了訊息佇列來輔助實現事務控制流程，其核心通過訊息佇列的方式來非同步執行分布式處理的任務，如果事務失敗，則可以發起人工重試的糾正流程（比如對賬系統，對處於dead letter queue的問題進行處理）
訊息傳送一致性
微服務架構下，需要通過網路進行通訊，就自然引入了資料傳輸的不確定性，也就是cap原理中的p-分割槽容錯，而這裡的訊息傳送一致性是可靠訊息的保證。
生成訊息的業務動作與訊息傳送的一致（e.g： 如果業務操作成功，那麼由這個業務操作所產生的訊息一定會成功投遞出去，否則就丟失訊息）
最終一致性.png
如上圖，保證訊息傳送一致性的一般流程如下：
訊息的ack確認流程中，任何乙個環節都可能會出問題！
對未ack的訊息，採用按規則重新投遞的方式進行處理（很多mq都提供at least once的投遞，持久化和重試機制），一般還會設定重發的次數， 超過次數的訊息會進入dead letter queue，等待人工干預或者延後定時處理。
業務介面的冪等性
訊息的重**送會導致業務介面出現重複呼叫的問題，主要原因就是訊息沒有及時收到ack確認導致的， 那如何實現冪等性設計呢？
在實際的業務場景中， 業務介面的冪等性設計，常結合查詢操作一起使用，
比如根據唯一標識查詢訊息是否被處理過， 或者根據消費日誌表，來維護訊息消費的記錄。
保證最終一致性的模式
分布式事務一致性，事務補償實戰
一 事務記錄補償表設計 三 業務補償函式 override public void compensation bidpaymentdetailconfirmrecord confirmrecord,providerusersession usersession throws exception bi...
用友微服務事務一致性實踐
本文就微服務事務一致性問題產生根源 業界常用方案優缺點進行了分析對比，在此基礎上提出了用友微服務事務一致性解決方案，詳細介紹了用友cc事務模型及原理，以及此方案解決的場景。在傳統巨石應用架構模式下，架構特點主要是mvc模式，由controller層負責對外提供服務介面，所有功能集中在乙個服務例項中，...
強一致性 弱一致性 最終一致性
這種方式在es等分布式系統中也有體現，可以設定主shard提交即返回成功，或者需要replica shard提交成功再返回。提到分布式架構就一定繞不開 一致性 問題，而 一致性 其實又包含了資料一致性和事務一致性兩種情況，本文主要討論資料一致性 事務一致性指acid 複製是導致出現資料一致性問題的唯...