分布式事務說的就是乙個事務的兩個或者多個操作不是在乙個資料庫中進行的，而是在多個資料庫中執行。
這個時候，如何保證事務操作的原子性和一致性？
舉個支付的例子，支付進行買東西。事務由兩個行為組成，我的購買商品資料表資料＋1，支付金額表資料－1。
如果這兩個都是在同一庫中，沒啥問題。
try catch 事務失敗二階段提交（2pc）增加了事務處理器和事務執行者的角色。由事務處理器來進行整個事務的處理。主要流程如下面的圖
當開始事務呼叫的時候，事務處理器向事務執行者（有可能是資料庫本身支援）發出命令，事務執行者進行prepare操作。
當所有事務執行者都完成了prepare操作，就進行下一步行為。
如果有乙個事務執行者在執行prepare的時候失敗了，那麼通知事務處理器，事務處理器再通知所有的事務執行者執行回滾操作。
當所有事務執行者都prepare成功以後，事務處理器會再次傳送commit請求給事務執行者，所有事務執行者進行commit處理。
當所有commit處理都成功了，那麼事務執行結束。
如果有乙個事務執行者的commit處理不成功，這個時候就要通知事務處理器，事務處理器通知所有的事務執行者執行回滾(abort)操作。
但是兩階段提交的詬病就是在於效能問題。比如由於執行鏈比較長，鎖定資源的時間也變長了。所以在高效能的系統中都會避免使用二階段提交。
這種方法是文章如何用訊息系統避免分布式事務？中提到的方法。
首先這種方法必須在產品上有所妥協。比如支付過程，在支付操作之後，並不是立即返回告知使用者你是否成功，並且扣除金額（當然如果訊息佇列通暢的情況下看起來是立即返回的）。
而是在支付的過程中，先恭喜你獲取物品成功，然後獲取物品成功後通知訊息佇列，由訊息佇列再進行扣除金額的操作。
當然訊息佇列有可能操作失敗，操作失敗以後由於有憑證，可以進行重試操作。
最終支付成功後，再進行訊息確認，從而保證訊息一致性。
如何用訊息系統避免分布式事務？
說說分布式事務 四
預建立訂單失敗 如果實際預建立訂單成功,訂單定時補償機制,定時刪除這部分訂單,不影響資料一致性,下單失敗 預扣減庫存失敗 如果預扣減庫存真實失敗,則下單失敗 訂單由定時補償機制定時刪除,其它應用參照場景4的處理方式,下單失敗 如果實際預扣減庫存成功,參照場景4的處理方式,下單失敗 實際建立訂單失敗 ...
說說分布式事務 三
tcc是由支付寶架構師提供的一種柔性解決分布式事務解決方案,主要包括三個步驟 tcc的關鍵流程如下圖 以下單和扣減庫存為例子 q 預生成訂單失敗了,為什麼要通過tcc執行預處理資料回滾?a 可能預生成訂單成功,但是介面返回失敗 超時失敗 所以預處理在某些情況下是有預處理資料,需要清理 在整個流程,我...
分布式 分布式事務
是資料庫執行過程中的乙個邏輯單位，由乙個有限的資料庫操作序列構成。事務的acid四大特性 原子性 atomicity 事務作為乙個整體被執行。一致性 consistency 從乙個一致的狀態轉換到另乙個一致的狀態。隔離性 isolation 多個事務併發執行時，併發事務之間互相影響的程度。永續性 d...