xa是乙個分布式事務協議，由tuxedo提出。xa中大致分為兩部分：事務管理器和本地資源管理器。其中本地資源管理器往往由資料庫實現，比如oracle、db2這些商業資料庫都實現了xa介面，而事務管理器作為全域性的排程者，負責各個本地資源的提交和回滾。xa實現分布式事務的原理如下：
總的來說，xa協議比較簡單，而且一旦商業資料庫實現了xa協議，使用分布式事務的成本也比較低。但是，xa也有致命的缺點，那就是效能不理想，特別是在交易下單鏈路，往往併發量很高，xa無法滿足高併發場景。xa目前在商業資料庫支援的比較理想，在mysql資料庫中支援的不太理想，mysql的xa實現，沒有記錄prepare階段日誌，主備切換回導致主庫與備庫資料不一致。許多nosql也沒有支援xa，這讓xa的應用場景變得非常狹隘。
所謂的訊息事務就是基於訊息中介軟體的兩階段提交，本質上是對訊息中介軟體的一種特殊利用，它是將本地事務和發訊息放在了乙個分布式事務裡，保證要麼本地操作成功並且對外發訊息成功，要麼兩者都失敗，開源的rocketmq就支援這一特性，具體原理如下：
1、a系統向訊息中介軟體傳送一條預備訊息
2、訊息中介軟體儲存預備訊息並返回成功
3、a執行本地事務
4、a傳送提交訊息給訊息中介軟體
通過以上4步完成了乙個訊息事務。對於以上的4個步驟，每個步驟都可能產生錯誤，下面一一分析：
基於訊息中介軟體的兩階段提交往往用在高併發場景下，將乙個分布式事務拆成乙個訊息事務（a系統的本地操作+發訊息）+b系統的本地操作，其中b系統的操作由訊息驅動，只要訊息事務成功，那麼a操作一定成功，訊息也一定發出來了，這時候b會收到訊息去執行本地操作，如果本地操作失敗，訊息會重投，直到b操作成功，這樣就變相地實現了a與b的分布式事務。原理如下：
雖然上面的方案能夠完成a和b的操作，但是a和b並不是嚴格一致的，而是最終一致的，我們在這裡犧牲了一致性，換來了效能的大幅度提公升。當然，這種玩法也是有風險的，如果b一直執行不成功，那麼一致性會被破壞，具體要不要玩，還是得看業務能夠承擔多少風險。
分布式事務，本質上是對多個資料庫的事務進行統一控制，按照控制力度可以分為：不控制、部分控制和完全控制。不控制就是不引入分布式事務，部分控制就是各種變種的兩階段提交，包括上面提到的訊息事務+最終一致性、tcc模式，而完全控制就是完全實現兩階段提交。部分控制的好處是併發量和效能很好，缺點是資料一致性減弱了，完全控制則是犧牲了效能，保障了一致性，具體用哪種方式，最終還是取決於業務場景。作為技術人員，一定不能忘了技術是為業務服務的，不要為了技術而技術，針對不同業務進行技術選型也是一種很重要的能力！
事務 分布式事務解決方案
事務acid特性 事務隔離級別 指的是讀和寫同時出現時出現的資料不一致問題。事務的一致性問題 存在問題問題描述 髒讀 dirty read 針對的是單條資料。即乙個更新操作a修改了某一條資料，但尚未提交該事務，此時另乙個讀操作b來查詢該條資料，讀到的是修改後的但尚未提交的資料。不可重複讀 unrep...
分布式事務解決方案
一 結合mq訊息中介軟體實現的可靠訊息最終一致性 二 tcc補償性事務解決 三 最大努力通知型方案 第一種方案 可靠訊息最終一致性，需要業務系統結合mq訊息中介軟體實現，在實現過程中需要保證訊息的成功傳送及成功消費。即需要通過業務系統控制mq的訊息狀態 第二種方案 tcc補償性，分為三個階段tryi...
分布式事務解決方案
當資料庫單錶一年產生的資料超過1000w，那麼就要考慮分庫分表，具體分庫分表的原理在此不做解釋，以後有空詳細說，簡單的說就是原來的乙個資料庫變成了多個資料庫。這時候，如果乙個操作既訪問01庫，又訪問02庫，而且要保證資料的一致性，那麼就要用到分布式事務。所謂的soa化，就是業務的服務化。比如原來單機...