最終一致性方案之ebay模式
ebay在2023年公布了乙個關於base準則提到乙個分布式事務解決方案。ebay的方案其實是乙個最終一致性方案，它主要採用訊息佇列來輔助實現事務控制流程，方案的核心是將需要分布式處理的任務通過訊息佇列的方式來非同步執行，如果事務失敗，則可以發起人工重試的糾正流程。人工重試被更多的應用於支付場景，通過對賬系統對事後問題進行處理。
比如乙個很常見的場景：某個使用者產生了一筆交易，那麼需要在交易表中增加記錄，同時需要修改使用者表的金額（餘額），由於這兩個表屬於不同的遠端服務，所以就會涉及到分布式事務與資料一致性的問題
user
(id, name, amt_sold, amt_bought)
transaction
(xid, seller_id, buyer_id, amount)
begin
;insert
into
transaction
values
(xid, $seller_id, $buyer_id, $amount)
;update
user
set amt_sold = amt_sold + $amount where id = $seller_id;
update
user
set amt_bought = amt_bought + $amount where id = $buyer_id;
commit
;
先啟動乙個事務，更新交易表（transaction）後，並不直接更新user表，而是將要對user表進行的更新插入到訊息佇列中。
目標系統收到該訊息以後，啟動本地事務去對使用者表的餘額做調整
偽**bool result=dao.update();
if(result)
根據上面的偽**的實現方案，可能出現幾種情況
1.資料庫操作成功，向mq中投遞訊息也成功
2.運算元據庫失敗，不會向mq中投遞訊息
3.運算元據庫成功，但是向mq中投遞訊息時失敗，向外丟擲異常。資料庫操作回滾
對於上面幾種情況，問題都不大。那麼我們分析小消費端的問題
1.訊息出佇列以後，消費者對應的業務操作要執行成功。如果執行失敗，訊息不能失效或者丟失。需要保證訊息和業務操作一致
2.盡量避免訊息重複消費，如果重複消費，也不能影響業務的執行結果
對於第乙個問題，如何保證訊息不丟失
現在用的比較普遍的mq都具有持久化訊息的功能，如果消費者宕機或者消費失敗，都可以執行重試機制
對於如何避免訊息的重複消費
1.保證消費者的冪等性；也就是說如果佇列中的訊息因為網路異常導致傳送多次的情況下，仍然需要保證訊息被應用多次與應用一次產生的效果是一樣的
上面這種方式是非常經典的實現，基本避免了分布式事務，實現了「最終一致性」。
各大知名的電商平台和網際網路公司，幾乎都是採用類似的設計思路來實現「最終一致性」的。這種方式適合的業務場景廣泛，而且比較可靠。不過這種方式技術實現的難度比較大
保證最終一致性的模式
1.查詢模式
任何乙個服務操作都提供乙個查詢介面，用來向外部輸出操作執行的狀態。服務操作的使用方可以通過介面得知服務操作執行的狀態，然後根據不同狀態做不同的處理操作，為了能夠實現查詢，每個服務操作都需要有唯一的流水號
2.補償模式
有了查詢模式，我們就能夠得知操作所處的具體狀態，如果整個操作處於不正常狀態，我們需要修正操作中的出現問題的子操作。也許是要重新執行，或者取消已完成的操作。通過修復使得整個分布式系統達到最終一致。這個過程就是補償模式
根據發起形式又分為
自動恢復：通過對發生失敗操作的介面自動重試或者回滾已經完成的操作
通知運營：如果程式無法自動完成恢復，則通過運營人員手動進行補償
通知技術：通過監控或者告警通知到技術人員，通過技術手段進行修復
x/opendtp模型的支付寶的dts架構
dts(distributed transaction service)框架是由支付寶在x/opendtp模型的基礎上改進的乙個設計，定義了類似2pc的標準兩階段介面，業務系統只需要實現對應的介面就可以使用dts的事務功能。dts最大的特點是放寬了資料庫的強一致約束，保證了資料的最終一致性。
具體的流程：
tcc分為三個階段trying-confirming-canceling。每個階段做不同的處理。lock、 commit、 rollback
trying 階段主要是對業務系統做檢測及資源預留
confirming 階段主要是對業務系統做確認提交，trying階段執行成功並開始執行confirming階段時，預設 confirming階段是不會出錯的。即：只要trying成功，confirming一定成功。
canceling 階段主要是在業務執行錯誤，需要回滾的狀態下執行的業務取消，預留資源釋放。
以上所有的操作需要滿足冪等性，冪等性的實現方式可以是：
1、通過唯一鍵值做處理，即每次呼叫的時候傳入唯一鍵值，通過唯一鍵值判斷業務是否被操作，如果已被操作，則不再重複操作
2、通過狀態機處理，給業務資料設定狀態，通過業務狀態判斷是否需要重複執行
如何更通俗的理解tcc事務模型
分布式事務解決方案（二）
本文 分布式事務的一致性分為兩種，實時一致性和最終一致性，實時一致性要求的客戶可接受的時間內完成資料操作，最終一致性要求在較長的時間內保證資料一致即可。實時一致性的解決方案有二階段提交協議 三階段提交協議和paxos演算法等。1.2兩階段提交協議 2pc 二階段提交 two phasecommit ...
事務 分布式事務解決方案
事務acid特性 事務隔離級別 指的是讀和寫同時出現時出現的資料不一致問題。事務的一致性問題 存在問題問題描述 髒讀 dirty read 針對的是單條資料。即乙個更新操作a修改了某一條資料，但尚未提交該事務，此時另乙個讀操作b來查詢該條資料，讀到的是修改後的但尚未提交的資料。不可重複讀 unrep...
分布式事務解決方案
一 結合mq訊息中介軟體實現的可靠訊息最終一致性 二 tcc補償性事務解決 三 最大努力通知型方案 第一種方案 可靠訊息最終一致性，需要業務系統結合mq訊息中介軟體實現，在實現過程中需要保證訊息的成功傳送及成功消費。即需要通過業務系統控制mq的訊息狀態 第二種方案 tcc補償性，分為三個階段tryi...