背景

隨着微服務的普及，分佈式事務成爲了系統設計中不得不面對的一個問題，而分佈式事務的實現則十分複雜。本文彙總整理了分佈式事務現有的七種實現方案，分別對每種方案的核心原理、對事務ACID特性的支持及其適用場景等進行了對比分析和總結，個人愚見，不吝賜教。閱讀本文之前，需要你對數據庫事務的ACID、CAP理論、Base理論以及兩階段提交有一定的認知，不熟悉者請自行百度或者閱讀參考博客1、2、3和4。除此之外，在閱讀本文過程中，如果對某種方案不理解，強烈建議先閱讀對應方案中的參考博客後再閱讀本文中對應的介紹。

爲了便於後文敘述，這裏對ACID中的C（一致性）做一個強調：嚴格的事務一致性是使數據庫從一個一致性狀態變到另一個一致性狀態，且事務中間狀態不能被觀察到。

分佈式事務的七種實現方案：

1、基於可靠消息服務（基於可靠消息中間件）；

2、最大努力嘗試（基於消息中間件）；

3、TX-LCN（對LCN的實現）；

4、X/Open DTP模型（XA規範，基於兩階段提交）；

5、阿里DTS（基於TCC）；

6、華爲ServiceComb（對SAGA模式的實現）；

7、阿里GTS（開源產品爲Fescar，對XA協議改進後的實現）。

1、基於可靠消息服務

我們常見的消息中間件比如LinkedLin公司的Kafka、Rabbit科技有限公司的RabbitMQ以及Apache提供的ActiveMQ等等，都不支持事務。而阿里提供的RocketMQ則在解決了消息的順序性和重複消息冪等性的基礎上，實現了對事務的支持（詳見參考博客5）。因而基於RocketMQ，就可以實現分佈式事務（詳見參考博客6）。實際上，參考博客6中給出了兩套基於消息服務的實現方案：第一，基於本地消息服務的方案，針對的是消息中間件本身不支持事務的場景，需要從應用設計的角度實現消息數據的可靠性；第二，基於獨立消息服務的方案，針對的是消息中間件本身支持事務的場景。爲了便於後面對比分析，這裏貼出了基於獨立消息服務的設計方案：

基於可靠消息服務的分佈式事務方案的核心原理是對發送到消息中間件的消息進行“兩階段提交”，即先提交，執行完本地事務後再確認消息。通過這樣的機制，給事務的回滾提供了可能。如下圖所示。如果用ACID來衡量該方案，基於可靠消息服務的分佈式事務方案能保證事務的最終原子性和持久性，但無法保證一致性和隔離性。這裏在原子性前面加“最終”二字，是因爲基於消息的操作本質上屬於異步操作，顯然是非實時的。持久性自然不必多說。那麼爲什麼說該方案無法保證一致性和隔離性呢？由下圖可知，本地事務執行提交成功之後，纔會對消息進行確認，而這個時候，遠程事務還未提交，一致性顯然無法滿足。我們知道，數據庫的隔離性是通過鎖機制來保證的，因而基於可靠消息服務的分佈式事務方案要想滿足隔離性，往往還需要在事務發起方採用分佈式鎖機制。因而總的來說，基於可靠消息服務的分佈式方案適用於對業務的實時一致性以及事務的隔離性要求都不高的內部系統。

2、最大努力嘗試

最大努力嘗試方案和基於可靠消息服務一樣，都依賴於消息中間件（參考博客7）。不同的是，消息中間件不需要保證可靠性，分佈式事務的實現是依靠額外的校對系統或者報警系統（報警後人工處理）來保障的。因而和基於可靠消息服務一樣，最大努力嘗試的分佈式方案只能保證事務的最終原子性和持久性，無法保證一致性和隔離性。在應用場景方面，正如參考博客7中所說，最大努力嘗試方案常常用於對業務的實時一致性以及事務的隔離性要求都不高的內部系統或者跨企業的業務活動中。下圖爲最大努力嘗試的方案：

同基於可靠消息服務的方案一樣，最大努力嘗試方案能保證事務的最終原子性和持久性，但無法保證一致性和隔離性。儘管最大努力嘗試方案只能保證最終原子性和持久性，但因其實現十分簡單，常常成爲企業很多非核心業務的首選方案。

3、TX-LCN

由LCN的官網（參考博客8）可知，LCN是lock、confirm和notify三個單詞的縮寫。個人人爲，LCN方案是本文中七個方案中除了剛剛已經介紹的兩個基於消息中間件的方案之外，最容易理解的方案，因而將其排在第三位來介紹。正如其官網文檔（詳見參考博客8）所說，LCN並不產生事務，LCN只是本地事務的協調工。這就意味着，使用LCN的系統完全依賴於本地事務。遺憾的是，LCN的官網對其核心原理介紹得比較簡略，看完不得其要領，反而是在另外的博客（參考博客9和10）中相對詳細地介紹了其實現原理。

LCN中包含一個TxManager和一個TxClient。其中TxManager負責維護全局的事務信息，而TxClient位於業務模塊和本地事務層之間，其作用是代理本地事務層，通過代理連接詞實現了javax.sql.DataSource接口，並重寫了close方法，事務模塊在提交關閉以後TxClient連接池將執行"假關閉"操作，等待TxManager協調完成事務以後在關閉連接，如下圖所示。

LCN的核心步驟

1. 創建事務組
是指在事務發起方開始執行業務代碼之前先調用TxManager創建事務組對象，然後拿到事務標示GroupId的過程。
2. 添加事務組
添加事務組是指參與方在執行完業務方法以後，將該模塊的事務信息添加通知給TxManager的操作。
3. 關閉事務組
是指在發起方執行完業務代碼以後，將發起方執行結果狀態通知給TxManager的動作。當執行完關閉事務組的方法以後，TxManager將根據事務組信息來通知相應的參與模塊提交或回滾事務。

以數據庫爲例，前面提到的“假關閉”就是指步驟2中執行完業務方法後調用的close()方法是覆寫後的方法，該方法並不會真正提交事務，而是一直持有數據庫連接，並持有事務所需的相關資源鎖，直到第3步，由TxManager異步通知事務提交或回滾才釋放鎖。

以參考博客10中的時序圖爲例（見下圖），參與方A和參與方B在執行完業務操作後，事務實際上並未提交，而是將提交前本地事務的操作結果返回給事務發起方，由事務發起方通知TxManager，並由後者根據通知的結果來異步通知各參與方最終提交或回滾事務。當然TxManager對參與方的通知可能會失敗，因而需要補償機制。

由此可知，LCN中的三個單詞對應了LCN分佈式事務操作中的三個關鍵步驟：1、分佈式事務操作前先鎖定（lock）所有資源直到異步通知（notify）釋放資源；2、執行業務操作，根據操作結果確認（confirm）事務應該提交還是回滾；3、根據第2步中的操作結果異步通知（notify）事務的提交或回滾並最終釋放資源。

至此，我們瞭解到，LCN的核心原理是通過協調本地事務來實現分佈式事務，分佈式事務的實現依賴於本地事務。因而基於LCN的分佈式事務的ACID特性取決於本地事務的ACID特性。一般來說，如果本地事務都能保證ACID，那麼基於LCN的分佈式事務也能滿足AID。而對於一致性（Consistency），這是分佈式事務的一個通病。由Base理論可知，對於分佈式系統，我們更關注的是最終一致性和最終一致性的實時性。相對於前面介紹的基於消息中間件的兩種方案來說，基於LCN的分佈式事務方案最終一致性的實時性遠高於前兩者。當然，其代價是併發性能的極大降低。實際上，對於分佈式系統而言，能做到準實時的最終一致性就已經能滿足絕大多數應用場景。對於像銀行業務等對一致性有極致要求的極端場景，還可以通過在業務系統中使用分佈式鎖或者分佈式隊列來保證。

小結：LCN方案相對於後面將要介紹的其他方案來說，其優點是實現相對簡單，但其缺點也是顯然的：第一，依賴本地事務，如果要操作的資源不支持本地事務，則LCN模式無法直接使用。當然，對於這個限制，新版的TX-LCN通過支持後面將會介紹的TCC模式和TXC模式來解決。第二，LCN事務提交的整個過程都需要鎖住資源，因而性能低於TCC和TXC（TCC和TXC就是爲了縮短分佈式事務操作過程中資源的鎖定時間）。

4、基於XA規範的X/Open DTP模型

X/Open，即現在的open group，是一個獨立的組織，主要負責制定各種行業技術標準。X/Open DTP即爲該組織制定的一套分佈式事務的方案。關於該模型詳細的介紹請閱讀參考博客11，這裏只介紹其最核心的原理。

DTP模型元素

應用程序(Application Program ，簡稱AP)：用於定義事務邊界(即定義事務的開始和結束)，並且在事務邊界內對資源進行操作。

資源管理器(Resource Manager，簡稱RM)：如數據庫、文件系統等，並提供訪問資源的方式。

事務管理器(Transaction Manager ，簡稱TM)：負責分配事務唯一標識，監控事務的執行進度，並負責事務的提交、回滾等。

通信資源管理器(Communication Resource Manager，簡稱CRM)：控制一個TM域(TM domain)內或者跨TM域的分佈式應用之間的通信。

通信協議(Communication Protocol，簡稱CP)：提供CRM提供的分佈式應用節點之間的底層通信服務。

這裏我們重點看看AP、TM和RM之間的關係：

由上圖可知，XA規範的最主要作用是，定義了RM-TM的交互接口。實際上，XA規範除了定義的RM-TM交互的接口之外，還對兩階段提交協議進行了優化。具體的優化包括只讀斷言和一階段提交。具體請閱讀參考博客11。

接下來我們來看XA規範的具體工作原理。參考博客14中給出了XA規範提交流程示意圖：

提交步驟爲：

在開始一個全局事務之前，涉及的RM必須通過ax_regr()，向TM註冊以加入集羣；對應的，在沒有事務需要處理的時候，RM可以通過ax_unreg()向TM要求註銷，離開集羣。
TM在對一個RM執行xa_開頭的具體操作前，必須先通過xa_open()打開這個RM（本質是建立對話）——這其實也是分配XID的一個行爲；與之相應的，TM執行xa_close()來關閉RM。
TM對RM調用的xa_start()和xa_stop()這對組合，一般用於標記局部事務的開頭和結尾。這裏需要注意的有三點：
對於同一個RM，根據全局事務的要求，可以前後執行多對組合——俾如說，先標記一個流水賬INSERT的局部事務操作，然後再標記賬戶UPDATE的局部事務操作。
TM執行該組合只是起到標記事務的作用，具體的業務命令是由AP交給RM的。
該組合除了執行這些標記工作外，其實還能在RM中實現多線程的join/suspend/resume管理。
TM調用RM的xa_prepare()來進行第一階段，調用xa_commit()或xa_rollback()執行第二階段。

這裏需要強調的是，XA規範中，整個兩階段提交過程資源都是處於鎖定狀態（見下圖）。在下圖中，無論Phase2的決議是commit還是rollback，事務性資源的鎖都要保持到Phase2完成才釋放。由此可知，基於XA規範的X/Open DTP和LCN都存在資源長期鎖定的問題。

小結：X/Open DTP的核心原理是基於兩階段提交（XA規範），通過在整個提交過程中對資源進行鎖定來實現分佈式事務，能很好地滿足AID特性，以及準實時的最終一致性。此外，該方案同LCN類似，性能低於TCC和TXC。因而在實際應用中，較少有系統會選擇該方案。

5、基於TCC的支付寶DTS

關於TCC原理，強烈建議先閱讀參考博客12和13。這裏給出參考博客13中的示意圖：

TCC 分佈式事務模型包括三部分：

主業務服務：主業務服務爲整個業務活動的發起方，服務的編排者，負責發起並完成整個業務活動。
從業務服務：從業務服務是整個業務活動的參與方，負責提供 TCC 業務操作，實現初步操作（Try）、確認操作（Confirm）、取消操作（Cancel）三個接口，供主業務服務調用。
業務活動管理器：業務活動管理器管理控制整個業務活動，包括記錄維護 TCC 全局事務的事務狀態和每個從業務服務的子事務狀態，並在業務活動提交時調用所有從業務服務的 Confirm 操作，在業務活動取消時調用所有從業務服務的 Cancel 操作。

一個完整的 TCC 分佈式事務流程如下：

1. 主業務服務首先開啓本地事務；

2. 主業務服務向業務活動管理器申請啓動分佈式事務主業務活動；

3. 然後針對要調用的從業務服務，主業務活動先向業務活動管理器註冊從業務活動，然後調用從業務服務的 Try 接口；

4. 當所有從業務服務的 Try 接口調用成功，主業務服務提交本地事務；若調用失敗，主業務服務回滾本地事務；

5. 若主業務服務提交本地事務，則 TCC 模型分別調用所有從業務服務的 Confirm 接口；若主業務服務回滾本地事務，則分別調用 Cancel 接口；

6. 所有從業務服務的 Confirm 或 Cancel 操作完成後，全局事務結束。

小結：以ACID來衡量TCC可知，TCC能滿足AID特性，以及準實時的最終一致性。TCC的核心原理是，在分佈式事務操作中，先將所需資源預佔，然後將鎖釋放，最後再根據資源預佔的情況來決定使用資源還是退回資源。相比於XA規範，TCC方案採用預留資源的方式，將兩階段提交過程中的全局鎖分成了兩段本地事務鎖，縮短了分佈式資源鎖定的時間，從而提高了事務的併發度。相對於後面即將介紹的SAGA而言，因爲TCC採用預佔資源的方式，其補償動作實現比較簡單。當然，TCC的缺點是業務入侵性大，尤其是已有業務如果想使用TCC方案，就需要修改原來的業務邏輯（後面介紹SAGA時還會再強調這一點）。

6、基於SAGA的華爲ServiceComb

saga是1987年的一篇數據庫論文裏提到的一個概念（參考博客16～19，重點是16），而ServiceComb是華爲一個項目組對saga模式的實現方案。論文中指出，一個Saga事務就是一個Long Live Transaction(LLT)，而一個LLT可以分解爲多個本地事務所組成，即LLT= T1 + T2 + ... + Tn。每個本地事務執行完提交之後就會立即生效，比如執行完T1和T2之後，在執行T3時，T1和T2的事務就已經提交了。假如執行T3失敗，由於T1和T2已經提交，無法回滾了。爲了解決這個問題，saga要求業務服務方對每個本地事務Tx都提供對應的反向補償操作Cx（反向補償是指Tx的逆向操作），反向補償操作也是執行完就立即生效。在執行一個LLT的過程中，如果任意一個Tx出錯了，則通過調用所有已執行的Tx對應的Cx來進行反向補償。比如執行完T1和T2之後，執行T3時出錯，則需要執行C3、C2和C1來進行補償。

論文中對被saga調用的服務提出了兩點要求：其一是被調用的服務要支持冪等。由於分佈式服務一定存在網絡超時，所以這一點對於分佈式服務來說，一般都能滿足。其二是服務要滿足可交換補償。如圖所示：

這裏有必要對可交換補償做一下說明。其實服務支持冪等和服務滿足可交換補償這兩點要求是爲了處理執行補償操作時必然會遇到的兩個細分場景。我們首先來說說執行補償操作時會遇到的哪兩個場景：第一，事務操作Tx根本未被執行（比如因網絡丟包導致事務操作Tx在圖中被丟棄，未到達服務端，或者在服務端執行失敗）。對於這種場景，Cx無須也不能執行，否則反而會出錯，也就是說，saga執行Cx操作的前提是服務方確實執行了Tx操作（成功或失敗均可）；第二，如上圖中的右圖所示，事務操作T發出後事務操作在網絡中出現了較大的延時，觸發了saga的超時機制，因而執行了正向重試，發現重試失敗，接着執行反向補償操作C，當C已經執行完之後，最開始的事務操作T纔到達服務方。這個時候，saga要求最開始的事務操作T不能生效，因爲C已經生效了。也就是說，saga要求服務一旦接受並執行了反向補償操作C，則不會再處理與之對應的正向操作。這麼做的目的是爲了防止先到達的反向補償操作被後到達的正向事務操作給覆蓋掉。其實場景二的實現依賴場景一中提供的保障，因爲示例中正向的重試操作也有可能無法到達服務端，這就變成了場景一了。其實這個問題在後面介紹的TCC方案中也會遇到，並需要被解決（有興趣可提前看參考博客20）。

除此之外，參考博客16中還說明了saga模式本身只支持ACID中的ACD，而無法支持隔離性（而如果用本文的評判標準來看，saga也無法只能滿足準實時的一致性，而無法滿足強一致性）。爲了支持隔離性，需要考慮在業務層加入鎖機制或者類似TCC的方式，採用在業務層預先凍結資源的方式對資源進行隔離。

關於saga模式的隔離性我還想補充說明的是，因爲saga模式的本地事務是執行完就立即提交，而不能回滾，那麼在沒有隔離性保障的情況下，反向補償操作很可能無法執行成功。比如說有A和B和C三個賬戶，賬戶餘額都爲100元，執行如下兩個併發事務：

事務一	事務二
A -> B 100元（超時，實際執行成功）
	B -> C 200元（執行成功）
B -> A 100元（反向補償，補償失敗）

小結：saga模式的核心原理是，將一個全局事務分成若干個能獨立提交的本地事務，每個本地事務都對應一個反向補償操作，當本地事務提交失敗後，通過反向補償操作來取消本地事務的影響。相比於TCC，Saga缺少預留動作，導致某些業務的補償動作的實現比較麻煩，比如業務是發送郵件，在TCC模式下，先保存草稿（Try）再發送（Confirm），撤銷的話直接刪除草稿（Cancel）就行了。而Saga則就直接發送郵件了（Ti），如果要撤銷則得再發送一份郵件說明撤銷（Ci）。當然，對於另外一些簡單業務來說，Saga沒有預留動作也可以認爲是優點（詳見參考博客18）：

有些業務很簡單，套用TCC需要修改原來的業務邏輯，而Saga只需要添加一個補償動作就行了。
TCC最少通信次數爲2n，而Saga爲n（n=sub-transaction的數量）。
有些第三方服務沒有Try接口，TCC模式實現起來就比較tricky了，而Saga則很簡單。
沒有預留動作就意味着不必擔心資源釋放的問題，異常處理起來也更簡單（請對比Saga的恢復策略和TCC的異常處理）。

7、基於改進XA協議的阿里GTS

GTS，最初名爲TXC，是Taobao Transaction Constructor的縮寫，於2014年4月立項，2014年10月發佈了TXC 1.0版本，2015年12月發佈TXC 2.0版本，2017年2月阿里雲公測，外部更名爲GTS（Global Transaction Service）。2019年1月，阿里分佈式事務框架GTS開源了一個免費社區版Fescar。

前面在介紹XA規範的時候提到，兩階段提交過程資源都是處於鎖定狀態，爲了便於對比，我再次貼出XA規範的提交示意圖（參考博客21）：

由圖可知，無論Phase2的決議是commit還是rollback，事務性資源的鎖都要保持到Phase2完成才釋放。設想一個正常運行的業務，大概率是90%以上的事務最終應該是成功提交的，我們是否可以在 Phase1 就將本地事務提交呢？這樣 90% 以上的情況下，可以省去 Phase2 持鎖的時間，整體提高效率。

分支事務中數據的 本地鎖 由本地事務管理，在分支事務 Phase1 結束時釋放。
同時，隨着本地事務結束，連接也得以釋放。
分支事務中數據的 全局鎖（詳見參考博客25）在事務協調器側管理，在決議 Phase2 全局提交時，全局鎖馬上可以釋放。只有在決議全局回滾的情況下，全局鎖 才被持有至分支的 Phase2 結束。

這個設計，極大地減少了分支事務對資源（數據和連接）的鎖定時間，給整體併發和吞吐的提升提供了基礎。

當然，你肯定會問：Phase1 即提交的情況下，Phase2 如何回滾呢？首先，應用需要使用 Fescar 的 JDBC 數據源代理，也就是 Fescar 的 RM。

Phase1：

Fescar 的 JDBC 數據源代理通過對業務 SQL 的解析，把業務數據在更新前後的數據鏡像組織成回滾日誌，利用本地事務的 ACID 特性，將業務數據的更新和回滾日誌的寫入在同一個本地事務中提交。

這樣，可以保證：任何提交的業務數據的更新一定有相應的回滾日誌存在。

基於這樣的機制，分支的本地事務便可以在全局事務的 Phase1 提交，馬上釋放本地事務鎖定的資源。

Phase2：

如果決議是全局提交，此時分支事務此時已經完成提交，不需要同步協調處理（只需要異步清理回滾日誌），Phase2 可以非常快速地完成。

如果決議是全局回滾，RM 收到協調器發來的回滾請求，通過 XID 和 Branch ID 找到相應的回滾日誌記錄，通過回滾記錄生成反向的更新 SQL 並執行，以完成分支的回滾。

由此可知，Fescar的核心原理是，對業務SQL進行解析，把業務數據在更新前後的數據鏡像組織成回滾日誌，利用本地事務的ACID特性，將業務數據的更新和回滾日誌的寫入在同一個本地事務中提交。除此之外，爲了保證分佈式事務的隔離性，在事務協調器側還增加了一把全局鎖，以保證回滾日誌得以順利執行（可以回過頭再看看Saga方案中列舉的回滾失敗的示例）。

小結：以ACID來衡量Fescar可知，該方案能保證AID特性，以及準實時的最終一致性。實際上，對於分佈式系統，如果分佈式方案能同時保證AID特性以和準實時的最終一致性，就等價於能保證增刪改操作的ACID特性，而至於查詢操作，可能會讀取到事務中間狀態的數據，這在絕大多數業務場景中都是能接受的。而且前面也講了，對於像銀行業務等對一致性有極致要求的極端場景，也可以通過在業務系統中使用分佈式鎖或者分佈式隊列來保證。

總結

基於可靠消息中間件的分佈式方案的核心原理是對發送到消息中間件的消息進行“兩階段提交”，即先提交，執行完本地事務後再確認消息。通過這樣的機制，給事務的回滾提供了可能。該方案能保證事務的最終原子性和持久性，但無法保證一致性和隔離性。基於可靠消息服務的分佈式方案適用於對業務的實時一致性以及事務的隔離性要求都不高的系統。

最大努力嘗試方案的核心原理是依靠額外的校對系統或者報警系統來保證分佈式事務。該方案能保證事務的最終原子性和持久性，但無法保證一致性和隔離性。基於可靠消息服務的分佈式方案適用於對業務的實時一致性以及事務的隔離性要求都不高的系統。

TX-LCN方案的核心原理是通過協調本地事務來實現分佈式事務，分佈式事務的實現依賴於本地事務。一般來說，如果本地事務都能保證ACID，那麼基於LCN的分佈式事務也能滿足AID，而不能滿足一致性。TX-LCN實現相對簡單，但事務對資源的鎖定時間長，因而適用於對併發性能要求不高的場景。

X/Open DTP的核心原理是基於兩階段提交（XA規範），通過在整個提交過程中對資源進行鎖定來實現分佈式事務，能很好地滿足AID特性，以及準實時的最終一致性。由於該方案對資源的鎖定時間長，因而適用於對併發性能要求不高的場景。

TCC的核心原理是，在分佈式事務操作中，先將所需資源預佔，然後將鎖釋放，最後再根據資源預佔的情況來決定使用資源還是退回資源。相比於XA規範，TCC方案採用預留資源的方式，將兩階段提交過程中的全局鎖分成了兩段本地事務鎖，縮短了分佈式資源鎖定的時間，從而提高了事務的併發度。

saga模式的核心原理是，將一個全局事務分成若干個能獨立提交的本地事務，每個本地事務都對應一個反向補償操作，當本地事務提交失敗後，通過反向補償操作來取消本地事務的影響。相比於TCC，Saga缺少預留動作，導致某些業務的補償動作的實現比較麻煩，比如業務是發送郵件，但對於另外一些簡單業務來說，Saga沒有預留動作的特性降低了老系統接入Saga方案的成本。

Fescar的核心原理是，對業務SQL進行解析，把業務數據在更新前後的數據鏡像組織成回滾日誌，利用本地事務的ACID特性，將業務數據的更新和回滾日誌的寫入在同一個本地事務中提交。此外，爲了保證分佈式事務的隔離性，在事務協調器側還增加了一把全局鎖，以保證回滾日誌得以順利執行。

參考博客：

1、https://blog.csdn.net/shuaihj/article/details/14163713 談談數據庫的ACID

2、https://www.cnblogs.com/szlbm/p/5588543.html 從分佈式一致性談到CAP理論、Base理論

3、https://www.jdon.com/46956 ACID中C與CAP定理中C的區別

4、https://www.jianshu.com/p/18b511c037a9 兩階段提交與三階段提交

5、http://www.sohu.com/a/129521820_487514 阿里RocketMQ如何解決消息的順序&重複兩大硬傷

6、https://blog.csdn.net/qq_27384769/article/details/79308210 分佈式事務八_可靠消息最終一致性方案

7、https://blog.csdn.net/qq_27384769/article/details/79331027 分佈式事務10_最大努力通知

8、 https://www.txlcn.org/zh-cn/docs/background.html LCN背景

9、https://blog.csdn.net/gududedabai/article/details/83012487 LCN分佈式事務框架原理詳解4.0

10、https://blog.csdn.net/qq_28341873/article/details/79789054 TX-LCN分佈式事務原理介紹