場景：a資料庫有乙個人叫小明，b資料庫有乙個人叫小花，現在小明要給小花轉賬100，那麼就有兩個操作，小明賬戶-100，小 花賬戶+100，由於是跨資料庫，事務在此時沒用，那該如何保證兩人賬戶資料的準確。
方案一：
兩次提交，設計理念：在同乙個資料庫中，我們可以使用事務來保證資料的原子性。現在我們有兩個資料庫，就有兩個事 務，這兩個事務分別保證各自的原子性。我們引進乙個第三方，事務管理器，管理這兩個事務。小明賬戶-100，事務完成 待提交，反饋乙個資訊給事務管理器，告知a事務已準備好。小花賬戶+100，事務完成待 提交，同樣反饋乙個資訊給事務 管理器告知b事務已準備好。兩個都準備好了再統一提交，否則一方報錯全部回滾。瓶頸：1.多個事務必須等待其他事務共 同完成才能完成，阻塞性太大，再高併發情況下延遲太長。2.事務管理器萬一有問題，那麼事務都會陷於等待狀態。
進化一：
使用中介軟體訊息佇列，我們不期望能夠實現名義上的原子性，只要最終資料達成一致就行。小明賬戶-100操作已執行，但 小花賬戶到賬時間可以延長一段時間顯示，最終我們資料是一致的。在小明賬戶-100操作完成了，這時我們向訊息佇列中 寫入一條訊息，小花賬戶+100,。我們消費者讀到這條訊息時，再向小花轉賬。那麼小明賬戶-100事務和訊息佇列是兩個東 西，怎麼做到原子性呢？把訊息插入到佇列這塊**放到事務**的最後面嗎？如果事務提交了，訊息卻未插入到佇列就 會有問題了。
進化二：
我們沒有辦法保證事務和訊息佇列的原子性，那我們把訊息佇列出現場景稍微往後挪一下。我們引進一張事件表，當小明 賬戶-100，這時小花賬戶+100，把小花賬戶+100這個待執行事件寫入到事件表中。這樣都是sql，我們可以做到事務的原 子性了。我們再弄個定時器，將事件表中的待執行操作都寫入到訊息佇列中，把事件置為已執行，然後等待訊息消費就 行。這樣貌似已經可以完美的處理了，但還是有乙個問題。如果我們將待執行事件已寫入到訊息佇列，但這時候停電，事 件表中的資料未被置為已執行，下次讀取還是會寫入到訊息佇列中，最終小花可能會+200。
進化三：
我們再引入乙個概念：冪等性。大致意思就是：無論我操作乙個事務千萬次，資料始終不變。比如select * from查詢語句，
無論我們執行多少次，資料都不變。那麼小花到賬+100執行多次就會多次改變，但如果我只讓他執行一次呢。上面說到 可能訊息佇列會有兩條甚至多條小花賬戶+100。在b資料庫中同樣增加一張已處理事件表，記錄已處理的訊息。每次處理 訊息佇列時我們先判斷是否已執行過。
總結於：《碼農翻身》
分布式事務處理
前提如下 db a,db b為兩個資料庫 都有乙個person表 該錶兩個字段 personid 主鍵 和personname 下面的分布式事務 實現的是 同時向這兩個庫的兩個表新增資料 set xact abort on 開始分布式事務 begin distributed transaction ...
java 分布式事務處理
分布式事務處理 當資料分布在多個資料庫伺服器上時，就需要各種保護措施來保證資料正確地寫到所有資料庫中。例如，考慮乙個在三個分離的遠端資料庫上修改的 客戶帳戶平衡表，如果在事務寫階段，任何乙個資料庫連線失敗，資料庫之間就失去同步。怎樣檢測並更正這種情形呢？事務處理 tp 監示乙個叫做兩階段提交 的過程...
XA分布式事務處理
在談到 xa規範之前，必須首先了解分布式事務處理 distributed transaction processing dtp 的概念。transaction 即事務，又稱之為交易，指乙個程式或程式段，在乙個或多個資源如 資料庫 或檔案上為完成某些功能的執行過程的集合。分布式事務處理是指乙個事務可能...