xa是乙個分布式事務協議，由tuxedo提出。xa中大致分為兩部分：事務管理器和本地資源管理器。其中本地資源管理器往往由資料庫實現，比如oracle、db2這些商業資料庫都實現了xa介面，而事務管理器作為全域性的排程者，負責各個本地資源的提交和回滾。xa實現分布式事務的原理如下：
總的來說，xa協議比較簡單，而且一旦商業資料庫實現了xa協議，使用分布式事務的成本也比較低。但是，xa也有致命的缺點，那就是效能不理想，特別是在交易下單鏈路，往往併發量很高，xa無法滿足高併發場景。xa目前在商業資料庫支援的比較理想，在mysql資料庫中支援的不太理想，mysql的xa實現，沒有記錄prepare階段日誌，主備切換回導致主庫與備庫資料不一致。許多nosql也沒有支援xa，這讓xa的應用場景變得非常狹隘。
使用xa方式的效率低,使用訊息佇列消除分布式事務又太過複雜,基於效率和時間成本的考慮,我們選用spring的鏈式事務管理器也就是非xa方式 chainedtransactionmanager.他最大努力一階段提交模式中,乙個粗糙的事務管理器實現僅僅將一系列其他的事務管理器鏈結在一起,去實現事務的同步,倘若業務處理成功,所有的事務將會提交,否則他們會回滾,最大努力一次提交模式的安全性不如xa事務但是也是相當不錯的,因為能夠承受風險獲得較高的吞吐量收益,如果我們將關鍵業務處理服務設計為乙個幕等式(idempotent),這樣發生錯誤的可能性也很小.
所謂的訊息事務就是基於訊息中介軟體的兩階段提交，本質上是對訊息中介軟體的一種特殊利用，它是將本地事務和發訊息放在了乙個分布式事務裡，保證要麼本地操作成功成功並且對外發訊息成功，要麼兩者都失敗，開源的rocketmq就支援這一特性，具體原理如下：
1、a系統向訊息中介軟體傳送一條預備訊息
2、訊息中介軟體儲存預備訊息並返回成功
3、a執行本地事務
4、a傳送提交訊息給訊息中介軟體
通過以上4步完成了乙個訊息事務。對於以上的4個步驟，每個步驟都可能產生錯誤，下面一一分析：
基於訊息中介軟體的兩階段提交往往用在高併發場景下，將乙個分布式事務拆成乙個訊息事務（a系統的本地操作+發訊息）+b系統的本地操作，其中b系統的操作由訊息驅動，只要訊息事務成功，那麼a操作一定成功，訊息也一定發出來了，這時候b會收到訊息去執行本地操作，如果本地操作失敗，訊息會重投，直到b操作成功，這樣就變相地實現了a與b的分布式事務。原理如下：
雖然上面的方案能夠完成a和b的操作，但是a和b並不是嚴格一致的，而是最終一致的，我們在這裡犧牲了一致性，換來了效能的大幅度提公升。當然，這種玩法也是有風險的，如果b一直執行不成功，那麼一致性會被破壞，具體要不要玩，還是得看業務能夠承擔多少風險。
分布式 分布式事務
是資料庫執行過程中的乙個邏輯單位，由乙個有限的資料庫操作序列構成。事務的acid四大特性 原子性 atomicity 事務作為乙個整體被執行。一致性 consistency 從乙個一致的狀態轉換到另乙個一致的狀態。隔離性 isolation 多個事務併發執行時，併發事務之間互相影響的程度。永續性 d...
分布式事務 分布式事務的實現
如果在多個服務中需要對不同的資料庫進行操作。因為不同服務操作的資料庫都不同，所以保證在同乙個事務中完成操作顯然是不科學的。那實現分布式事務的思想 1 方法入口，建立一條日誌記錄，狀態定義為初始狀態，即儲存本條日誌記錄 可以儲存在資料庫中，也可以寫出到本地磁碟檔案 2 可以在非同步執行緒或在定時任務中...
分布式事務和事務併發控制
近期阿里開源了fescar分布式事務中介軟體,值得期待.分布式事務是指乙個事務會涉及到到多個應用介面呼叫,底層資料表涉及到多個,但資料庫可以是乙個或多個,它是傳統單資料庫事務在廣度上的延伸.事務併發控制,在oltp關係型資料庫中,事務併發控制往往是指事務的隔離性,在本文中,指的是應用層的併發事務控制...