分布式事務XA,JTA,兩階段送出,BASE

[size=small]關于分布式事務、兩階段送出、一階段送出、Best Efforts 1PC模式和事務補償機制的研究

[url]http://blog.csdn.net/bluishglc/article/details/7612811[/url]

作者：謝照東

連結：[url]http://www.zhihu.com/question/29483490/answer/107142534[/url]

來源：知乎

比如事務補償機制：即在事務鍊中的任何一個正向事務操作，都必須存在一個完全符合復原規則的可逆事務。

或者兩階段送出、三階段送出：分布式事務服務(DTS) 支付寶的DTS實作！最近也看見一個tcc方案GitHub - changmingxie/tcc-transaction: tcc-transaction是TCC型事務java實作 還沒有線上試過

或者利用消息系統（轉載自高可用架構公衆号）

經典方案 - eBay 模式

此方案的核心是将需要分布式處理的任務通過消息日志的方式來異步執行。消息日志可以存儲到本地文本、資料庫或消息隊列，再通過業務規則自動或人工發起重試。人工重試更多的是應用于支付場景，通過對賬系統對事後問題的處理。

消息日志方案的核心是保證服務接口的幂等性。

考慮到網絡通訊失敗、資料丢包等原因，如果接口不能保證幂等性，資料的唯一性将很難保證。

eBay 方式的主要思路如下。

Base：一種 Acid 的替代方案

此方案是 eBay 的架構師 Dan Pritchett 在 2008 年發表給 ACM 的文章，是一篇解釋 BASE 原則，或者說最終一緻性的經典文章。文中讨論了 BASE 與 ACID 原則在保證資料一緻性的基本差異。

如果 ACID 為分區的資料庫提供一緻性的選擇，那麼如何實作可用性呢？答案是

[b][color=red]BASE (basically available, soft state, eventually consistent)[/color][/b]

BASE 的可用性是通過支援局部故障而不是系統全局故障來實作的。下面是一個簡單的例子：如果将使用者分區在 5 個資料庫伺服器上，BASE 設計鼓勵類似的處理方式，一個使用者資料庫的故障隻影響這台特定主機那 20% 的使用者。這裡不涉及任何魔法，不過它确實可以帶來更高的可感覺的系統可用性。

文章中描述了一個最常見的場景，如果産生了一筆交易，需要在交易表增加記錄，同時還要修改使用者表的金額。這兩個表屬于不同的遠端服務，是以就涉及到分布式事務一緻性的問題。

[img]http://dl2.iteye.com/upload/attachment/0118/2804/80f6c2b2-3615-31a3-a538-30a509f47c11.png[/img]

文中提出了一個經典的解決方法，将主要修改操作以及更新使用者表的消息放在一個本地事務來完成。同時為了避免重複消費使用者表消息帶來的問題，達到多次重試的幂等性，增加一個更新記錄表 updates_applied 來記錄已經處理過的消息。

[img]http://dl2.iteye.com/upload/attachment/0118/2806/ab9d45d3-66c3-3fa2-aa9e-cca88f7bff17.png[/img]

系統的執行僞代碼如下

[img]http://dl2.iteye.com/upload/attachment/0118/2808/73f995ae-e132-3e00-b119-9f8601e341ef.png[/img]

基于以上方法，在第一階段，通過本地的資料庫的事務保障，增加了 transaction 表及消息隊列 。

在第二階段，分别讀出消息隊列（但不删除），通過判斷更新記錄表 updates_applied 來檢測相關記錄是否被執行，未被執行的記錄會修改 user 表，然後增加一條操作記錄到 updates_applied，事務執行成功之後再删除隊列。

通過以上方法，達到了分布式系統的最終一緻性。進一步了解 eBay 的方案可以參考文末連結。

或者在業務層面整合，整合成本地事務的方式。

Dubbo分布式事務

[url]http://javatar.iteye.com/blog/981787[/url]

[url]http://www.javaworld.com/article/2077963/open-source-tools/distributed-transactions-in-spring--with-and-without-xa.html[/url]

[/size]