分布式事務

1、基於xa協議的兩階段提交方案

交易中介軟體與資料庫通過 xa 介面規範，使用兩階段提交來完成乙個全域性事務， xa 規範的基礎是兩階段提交協議。

第一階段是表決階段，所有參與者都將本事務能否成功的資訊反饋發給協調者；第二階段是執行階段，協調者根據所有參與者的反饋，通知所有參與者，步調一致地在所有分支上提交或者回滾。

兩階段提交方案應用非常廣泛，幾乎所有商業oltp資料庫都支援xa協議。但是兩階段提交方案鎖定資源時間長，對效能影響很大，基本不適合解決微服務事務問題。

2、tcc方案

tcc方案在電商、金融領域落地較多。tcc方案其實是兩階段提交的一種改進。其將整個業務邏輯的每個分支顯式的分成了try、confirm、cancel三個操作。try部分完成業務的準備工作，confirm部分完成業務的提交，cancel部分完成事務的回滾。基本原理如下圖所示。

事務開始時，業務應用會向事務協調器註冊啟動事務。之後業務應用會呼叫所有服務的try介面，完成一階段準備。之後事務協調器會根據try介面返回情況，決定呼叫confirm介面或者cancel介面。如果介面呼叫失敗，會進行重試。

tcc方案讓應用自己定義資料庫操作的粒度，使得降低鎖衝突、提高吞吐量成為可能。當然tcc方案也有不足之處，集中表現在以下兩個方面：

上述原因導致tcc方案大多被研發實力較強、有迫切需求的大公司所採用。微服務倡導服務的輕量化、易部署，而tcc方案中很多事務的處理邏輯需要應用自己編碼實現，複雜且開發量大

3、基於訊息的最終一致性方案

訊息一致性方案是通過訊息中介軟體保證上、下游應用資料操作的一致性。基本思路是將本地操作和傳送訊息放在乙個事務中，保證本地操作和訊息傳送要麼兩者都成功或者都失敗。下游應用向訊息系統訂閱該訊息，收到訊息後執行相應操作。

訊息方案從本質上講是將分布式事務轉換為兩個本地事務，然後依靠下游業務的重試機制達到最終一致性。基於訊息的最終一致性方案對應用侵入性也很高，應用需要進行大量業務改造，成本較高。

公司實現方案

阿里基於tcc模型實現分布式事務

1、阿里gts

2、阿里gts微博：

主要開源框架：

框架名稱

巢狀呼叫

rpc框架支援

事務日誌儲存方式

git位址

star數量

tcc-transaction

不支援不耦合rpc框架，使用doubbo,thrift,web service,http等都可

db、redis、zk、file

hmily

不支援redis、mongodb、zk，file，db

bytetcc

不支援dubbo、springcloud

file

easytransaction

支援dubbo、springcloud

db、redis

開源tcc框架測試