在傳統的單體應用（包含單體應用的多份部署，比如使用反向代理等方式），業務code集中在一起，可以輕鬆保證事務的ACID；然而到了現在的微服務時代或者服務網格時代，單體應用被按照業務進行水平拆分，以前在一個事務內的業務代碼被分散到了多個進程之中，隨之帶來了令人煩惱的分佈式事務問題，如何保證進程之間事務完整性成爲了微服務帶來的難題，此篇將分享之前對分佈式事務的研究，包含對幾個業界知名框架的研究。
知名的CAP理論
CAP理論：指的是在一個分佈式系統中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分區容錯性），三者不可得兼。
一致性（C）：在分佈式系統中的所有數據備份，在同一時刻是否同樣的值。（等同於所有節點訪問同一份最新的數據副本）
可用性（A）：在集羣中一部分節點故障後，集羣整體是否還能響應客戶端的讀寫請求。（對數據更新具備高可用性）
分區容忍性（P）：以實際效果而言，分區相當於對通信的時限要求。系統如果不能在時限內達成數據一致性，就意味着發生了分區的情況，必須就當前操作在C和A之間做出選擇。
CAP理論的精髓就是要麼AP，要麼CP，要麼AC，但是不存在CAP。如果在某個分佈式系統中數據無副本， 那麼系統必然滿足強一致性條件， 因爲只有獨一數據，不會出現數據不一致的情況，此時C和P兩要素具備，但是如果系統發生了網絡分區狀況或者宕機，必然導致某些數據不可以訪問，此時可用性條件就不能被滿足，即在此情況下獲得了CP系統，但是CAP不可同時滿足。
基於CAP理論，分佈式事務必須在AP和CP模式之間進行選擇，而A（可靠性）對於在線業務來說又是不可或缺的，所以最後對於分佈式事務的處理則演變爲現在的AP加數據最終一致性方案。
最終一致性
異於事務的強一致性，強調的是結果，能夠在較短的時間內完成數據的一致性，並不適用於對數據要求強一致性的場景，比如部分金融場景；實現最終一致性的方式也有很多，比如兩段式提交，TCC（try confirm cancel），最大努力通知等。
開源實現
-
其中應用程序(Application Program ，簡稱AP)：AP定義事務邊界（定義事務開始和結束）並訪問事務邊界內的資源。
-
資源管理器(Resource Manager，簡稱RM)：Rm管理計算機共享的資源，許多軟件都可以去訪問這些資源，資源包含比如數據庫、文件系統、打印機服務器等。
-
事務管理器(Transaction Manager ，簡稱TM)：負責管理全局事務，分配事務唯一標識，監控事務的執行進度，並負責事務的提交、回滾、失敗恢復等。
開源實現大部分都是2PC（兩段式提交），方案提供一個高可用的TM，並提供對應的Client（相當於RM），利用註解切面的方式和遠程調用是傳遞事務唯一標識，通過TM的協調進行監控，事務的提交回滾等。
-
TX-LCN：本人使用過的分佈式開源解決方案，現最新版本爲5.0.2，但是基本已經停止更新，bug不少，LCN模式的實現原理則是代理數據庫連接connection，代理commit方法與TM進行通訊，TM進行協調；本人使用的4.1.0版本依賴Redis，新版本嘗試過，因爲bug過多放棄，避可能指南：如果你使用的是spring cloud且使用了hystrix，注意不要使用線程池隔離模式。
-
SEATA：現階段最火的開源實現方案，阿里背書，藉助與Spring Cloud Alibaba社區非常活躍，如果你真的無法躲過分佈式事務的雷，可以嘗試。其原理也是代理連接，在業務數據庫中侵入一張表，來保存數據改變前或者後的image，回滾則使用侵入表的數據進行恢復，存在部分select for update操作，所以你使用時候可能需要關注性能下降，鎖表等情況；當然它同時也支持SAGA模式等。
-
RocketMQ：如果場景不是很多且不復雜，個人建議使用RocketMQ進行自己實現，利用RocketMQ的半消息完成事務的最終一致性。（由於最近也在使用RocketMQ，也發現了一些bug（比如Docker部署應用的時候client name會出現全部一樣的情況，導致負載均衡失敗），阿里的開源有點讓本人擔心）
最後，對於分佈式事務的問題，個人強烈建議能避開還是避開，不論使用那種方式都存在需要人工介入處理的情況，正所謂天下無難事，只要肯放棄！哈哈哈！