建站
咨詢
售后
建站咨詢
新聞中心
徹底掌握分布式事務(wù)2PC、3PC模型
作者：馬龍臺 2021-03-06 23:28:28
開發(fā)
架構(gòu)
分布式 事務(wù)是數(shù)據(jù)庫操作的最小工作單元，一組不可再分割的操作集合，是作為單個邏輯工作單元執(zhí)行的一系列操作。這些操作作為一個整體一起向系統(tǒng)提交，要么都執(zhí)行、要么都不執(zhí)行。
為阜南等地區(qū)用戶提供了全套網(wǎng)頁設(shè)計制作服務(wù)，及阜南網(wǎng)站建設(shè)行業(yè)解決方案。主營業(yè)務(wù)為網(wǎng)站制作、成都做網(wǎng)站、阜南網(wǎng)站設(shè)計，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務(wù)。我們深信只要達到每一位用戶的要求，就會得到認可，從而選擇與我們長期合作。這樣，我們也可以走得更遠！
本文轉(zhuǎn)載自微信公眾號「源碼興趣圈」，作者馬龍臺。轉(zhuǎn)載本文請聯(lián)系源碼興趣圈公眾號。
工作中使用最多的是本地事務(wù)，但是在對單一項目拆分為 SOA、微服務(wù)之后，就會牽扯出分布式事務(wù)場景
文章以分布式事務(wù)為主線展開說明，并且針對 2PC、3PC 算法進行詳細的講解，最后通過一個 Demo 來更深入掌握分布式事務(wù)，文章目錄結(jié)構(gòu)如下
- 什么是事務(wù)
- 什么是分布式事務(wù)
- DTP 模型和 XA 規(guī)范
- 什么是 DTP 模型
- 什么是 XA 規(guī)范
- 2PC 一致性算法
- 2PC-準備階段
- 2PC-提交階段
- 2PC 算法優(yōu)缺點
- 3PC 一致性算法
- JDBC 操作 MySQL XA 事務(wù)
- 結(jié)言
什么是事務(wù)
事務(wù)是數(shù)據(jù)庫操作的最小工作單元，一組不可再分割的操作集合，是作為單個邏輯工作單元執(zhí)行的一系列操作。這些操作作為一個整體一起向系統(tǒng)提交，要么都執(zhí)行、要么都不執(zhí)行
事務(wù)具有四個特征，分別是原子性(Atomicity)、一致性(Consistency)、隔離性(Isolation)和持久性(Durability)，簡稱為事務(wù)的 ACID 特性
如何保證事務(wù)的 ACID 特性?
- 原子性(Atomicity)：事務(wù)內(nèi) SQL 要么同時成功要么同時失敗，基于撤銷日志(undo 日志)實現(xiàn)
- 一致性(Consistency)：系統(tǒng)從一個正確態(tài)轉(zhuǎn)移到另一個正確態(tài)，由應(yīng)用通過 AID 來保證，可以說是事務(wù)的核心特性
- 隔離性(Isolation)：控制事務(wù)并發(fā)執(zhí)行時數(shù)據(jù)的可見性，基于鎖和多版本并發(fā)控制(mvcc)實現(xiàn)
- 持久性(Durability)：提交后一定存儲成功不會丟失，基于重做日志(redo log)實現(xiàn)
文章主要是介紹分布式事務(wù) 2PC 和 3PC，關(guān)于 redo、undo 日志、mvcc、鎖這塊的內(nèi)容后續(xù)再詳細介紹
在早些時候，我們應(yīng)用程序還是單體項目，所以操作的都是單一數(shù)據(jù)庫，這種情況下我們稱之為本地事務(wù)。本地事務(wù)的 ACID 一般都是由數(shù)據(jù)庫層面支持的，比如我們工作中常用的 MySQL 數(shù)據(jù)庫
平常我們在操作 MySQL 客戶端時，MySQL 會隱式對事務(wù)做自動提交，所以日常工作不會涉及手動書寫事務(wù)的創(chuàng)建、提交、回滾等操作。如果想要試驗鎖、MVCC等特性，可以創(chuàng)建多個會話，通過begin、commit、rollback等命令來試驗下不同事務(wù)之間的數(shù)據(jù)，看執(zhí)行結(jié)果和自己所想是否一致
我們平常開發(fā)項目代碼時使用的是 Spring 封裝好的事務(wù)，所以也不會手動編寫對數(shù)據(jù)庫事務(wù)的提交、回滾等方法(個別情況除外)。這里使用原生 JDBC 寫一個示例代碼，幫助大家理解如何通過事務(wù)保證 ACID 四大特性
- Connection conn = ...; // 獲取數(shù)據(jù)庫連接
- conn.setAutoCommit(false); // 開啟事務(wù)
- try {
- // ...執(zhí)行增刪改查sql
- conn.commit(); // 提交事務(wù)
- } catch (Exception e) {
- conn.rollback(); // 事務(wù)回滾
- } finally {
- conn.close(); // 關(guān)閉鏈接
- }
設(shè)想一下，每次進行數(shù)據(jù)庫操作，都要寫重復的創(chuàng)建事務(wù)、提交、回滾等方法是不是挺痛苦的，那 Spring 如何自動幫助我們管理事務(wù)的呢?Spring 項目中我們一般使用兩種方式來進行事務(wù)的管理，編程式事務(wù)和聲明式事務(wù)
項目中使用 Spring 管理事務(wù)，要么在接口方法上添加注解 @Transactional，要么使用 AOP 配置切面事務(wù)。其實這兩種方式大同小異，只不過 @Transactional 的粒度更細一些，實現(xiàn)原理上都是依賴 AOP，舉例說明下
- @Service
- public class TransactionalService {
- @Transactional
- public void save() {
- // 業(yè)務(wù)操作
- }
- }
TransactionalService 會被 Spring 創(chuàng)建一個代理對象放入到容器中，創(chuàng)建后的代理對象相當于下述類
- public class TransactionalServiceProxy {
- private TransactionalService transactionalService;
- public TransactionalServiceProxy(TransactionalService transactionalService) {
- this.transactionalService = transactionalService;
- }
- public void save() {
- try {
- // 開啟事務(wù)操作
- transactionalService.save();
- } catch (Exception e) {
- // 出現(xiàn)異常則進行回滾
- }
- // 提交事務(wù)
- }
- }
示例代碼看著簡潔明了，但是真正的代碼生成代碼對比要復雜很多。關(guān)于事務(wù)管理器，Spring 提供了接口 PlatformTransactionManager，其內(nèi)部包含兩個重要實現(xiàn)類
- DataSourceTransactionManager：支持本地事務(wù)，內(nèi)部通過java.sql.Connection來開啟、提交和回滾事務(wù)
- JtaTransactionManager：用于支持分布式事務(wù)，其實現(xiàn)了 JTA 規(guī)范，使用 XA 協(xié)議進行兩階段提交
通過這兩個實現(xiàn)類得知，平常我們使用的編程式事務(wù)和聲明式事務(wù)依賴于本地事務(wù)管理實現(xiàn)，Spring 同時也支持分布式事務(wù)，關(guān)于 JTA 分布式事務(wù)的支持網(wǎng)上資料挺多的，就不在這里贅述了
什么是分布式事務(wù)
日常業(yè)務(wù)代碼中的本地事務(wù)我們一直都在用，理解起來并不困難。但是隨著服務(wù)化(SOA)、微服務(wù)的流行，平常我們的單一業(yè)務(wù)系統(tǒng)被拆分成為了多個系統(tǒng)，為了迎合業(yè)務(wù)系統(tǒng)的變更，數(shù)據(jù)庫也結(jié)合業(yè)務(wù)進行了拆分
比如以學校管理系統(tǒng)舉例說明，可能就會拆分為學生服務(wù)、課程服務(wù)、老師服務(wù)等，數(shù)據(jù)庫也拆分為多個庫。當這種情況，把不同的服務(wù)部署到服務(wù)器，就會有可能面臨下述的服務(wù)調(diào)用
ServiceA 服務(wù)需要操作數(shù)據(jù)庫執(zhí)行本地事務(wù)，同時需要調(diào)用 ServiceB 和 ServiceC 服務(wù)發(fā)起事務(wù)調(diào)用，如何保證三個服務(wù)的事務(wù)要么一起成功或者一起失敗，如何保證用戶發(fā)起請求的事務(wù) ACID 特性呢?無疑這就是分布式事務(wù)場景，三個服務(wù)的單一本地事務(wù)都無法保證整個請求的事務(wù)
分布式事務(wù)場景有很多種解決方案，以不同分類來看，強一致性解決方案、最終一致性解決方案，細分其中的方案包括2PC、3PC、TCC、可靠消息...
業(yè)界中使用較多的像阿里的 RocketMQ 事務(wù)消息、Seata XA模式、可靠消息模型這幾種解決方案。不過，分布式事務(wù)無一例外都是會直接或間接操作多個數(shù)據(jù)庫，而且使用了分布式事務(wù)同時也會帶來新的挑戰(zhàn)，那就是性能問題。如果為了保證強一致性分布式事務(wù)亦或者補償方案的最終一致性，導致了性能的下降，對于正常業(yè)務(wù)而言，無疑是得不償失的
DTP 模型和 XA 規(guī)范
X/Open 組織定義了分布式事務(wù)的模型(DTP)和 分布式事務(wù)協(xié)議(XA)，DTP 由以下幾個模型元素組成
- AP(Application 應(yīng)用程序)：用于定義事務(wù)邊界(即定義事務(wù)的開始和結(jié)束)，并且在事務(wù)邊界內(nèi)對資源進行操作
- TM(Transaction Manager 事務(wù)管理器)：負責分配事務(wù)唯一標識，監(jiān)控事務(wù)的執(zhí)行進度，并負責事務(wù)的提交、回滾等
- RM(Resource Manager 資源管理器)：如數(shù)據(jù)庫、文件系統(tǒng)等，并提供訪問資源的方式
- CRM(Communication Resource Manager 通信資源管理器)：控制一個TM域(TM domain)內(nèi)或者跨TM域的分布式應(yīng)用之間的通信
- CP(Communication Protocol 通信協(xié)議)：提供CRM提供的分布式應(yīng)用節(jié)點之間的底層通信服務(wù)
在 DTP 分布式事務(wù)模型中，基本組成需要涵蓋 AP、TM、RMS(不需要 CRM、CP 也是可以的)，如下圖所示
XA 規(guī)范
XA 規(guī)范最重要的作用就是定義 RM(資源管理器)與 TM(事務(wù)管理器)之間的交互接口。另外，XA 規(guī)范除了定義 2PC 之間的交互接口外，同時對 2PC 進行了優(yōu)化
梳理下 DTP、XA、2PC 之間的關(guān)系
DTP 規(guī)定了分布式事務(wù)中的角色模型，并在其中指定了全局事務(wù)的控制需要使用 2PC 協(xié)議來保證數(shù)據(jù)的一致性
2PC 是 Two-Phase Commit 的縮寫，即二階段提交，是計算機網(wǎng)絡(luò)尤其是數(shù)據(jù)庫領(lǐng)域內(nèi)，為了保證分布式系統(tǒng)架構(gòu)下所有節(jié)點在進行事務(wù)處理過程中能夠保證原子性和一致性而設(shè)計的一種算法。同時，2PC 也被認為是一種一致性協(xié)議，用來保證分布式系統(tǒng)數(shù)據(jù)的一致性
XA 規(guī)范是 X/Open 組織提出的分布式事務(wù)處理規(guī)范，XA 規(guī)范定義了 2PC(兩階段提交協(xié)議)中需要用到的接口，也就是上圖中 RM 和 TM 之間的交互。2PC 和 XA 兩者最容易混淆，可以這么理解，DTP 模型定義 TM 和 RM 之間通訊的接口規(guī)范叫 XA，然后 關(guān)系數(shù)據(jù)庫(比如MySQL)基于 X/Open 提出的的 XA 規(guī)范(核心依賴于 2PC 算法)被稱為 XA 方案
2PC 一致性算法
當應(yīng)用程序(AP)發(fā)起一個事務(wù)操作需要跨越多個分布式節(jié)點的時候，每一個分布式節(jié)點(RM)知道自己進行事務(wù)操作的結(jié)果是成功或是失敗，但是卻不能獲取到其它分布式節(jié)點的操作結(jié)果。為了保證事務(wù)處理的 ACID 特性，就需要引入稱為"協(xié)調(diào)者"的組件(TM)來進行統(tǒng)一調(diào)度分布式的執(zhí)行邏輯
協(xié)調(diào)者負責調(diào)度參與整體事務(wù)的分布式節(jié)點的行為，并最終決定這些分布式節(jié)點要把事務(wù)進行提交還是回滾。所以，基于這種思想下，衍生出了二階段提交和三階段提交兩種分布式一致性算法協(xié)議。二階段指的是準備階段和提交階段，下面我們先看準備階段都做了什么事情
2PC-準備階段
二階段提交中第一階段也叫做"投票階段"，即各參與者投票表明自身是否繼續(xù)執(zhí)行接下來的事務(wù)提交步驟
- 事務(wù)詢問：協(xié)調(diào)者向所有參與本次分布式事務(wù)的參與者發(fā)送事務(wù)內(nèi)容，詢問是否可以執(zhí)行事務(wù)提交操作，然后開始等待各個參與者的響應(yīng)
- 執(zhí)行事務(wù)：參與者收到協(xié)調(diào)者的事務(wù)請求，執(zhí)行對應(yīng)的事務(wù)，并將內(nèi)容寫入 Undo 和 Redo 日志
- 返回響應(yīng)：如果各個參與者執(zhí)行了事務(wù)，那么反饋協(xié)調(diào)者 Yes 響應(yīng);如果各個參與者沒有能夠成功執(zhí)行事務(wù)，那么就會返回協(xié)調(diào)者 No 響應(yīng)
如果第一階段全部參與者返回成功響應(yīng)，那么進入事務(wù)提交步驟，反之本次分布式事務(wù)以失敗返回。以 MySQL 數(shù)據(jù)庫為例，在第一階段，事務(wù)管理器(TM)向所有涉及到的數(shù)據(jù)庫(RM)發(fā)出 prepare(準備提交) 請求，數(shù)據(jù)庫收到請求后執(zhí)行數(shù)據(jù)修改和日志記錄處理，處理完成后把事務(wù)的狀態(tài)修改為 "可提交"，最終將結(jié)果返回給事務(wù)處理器
2PC-提交階段
提交階段分為兩個流程，一個是各參與者正常執(zhí)行事務(wù)提交流程，并返回 Yes 響應(yīng)，表示各參與者投票執(zhí)行成功;一個是各參與者當中有執(zhí)行失敗返回 No 響應(yīng)或超時情況，將觸發(fā)全局回滾，表示分布式事務(wù)執(zhí)行失敗
- 執(zhí)行事務(wù)提交
- 中斷事務(wù)
執(zhí)行事務(wù)提交
假設(shè)協(xié)調(diào)者從所有的參與者獲得的反饋都是 Yes 響應(yīng)，那么就會執(zhí)行事務(wù)提交操作
- 事務(wù)提交：協(xié)調(diào)者向所有參與者節(jié)點發(fā)出 Commit 請求，各個參與者接收到 Commit 請求后，將本地事務(wù)進行提交操作，并在完成提交之后釋放事務(wù)執(zhí)行周期內(nèi)占用的事務(wù)資源
- 完成事務(wù)：各個參與者完成事務(wù)提交之后，向協(xié)調(diào)者發(fā)送 Ack 響應(yīng)，協(xié)調(diào)者接收到響應(yīng)后完成本次分布式事務(wù)
中斷事務(wù)
假設(shè)任意一個事務(wù)參與者節(jié)點向協(xié)調(diào)者反饋了 No 響應(yīng)(注意這里的 No 響應(yīng)指的是第一階段)，或者在等待超時之后，協(xié)調(diào)者沒有接到所有參與者的反饋響應(yīng)，那么就會進行事務(wù)中斷流程
- 事務(wù)回滾：協(xié)調(diào)者向所有參與者發(fā)出 Rollback 請求，參與者接收到回滾請求后，使用第一階段寫入的 undo log 執(zhí)行事務(wù)的回滾，并在完成回滾事務(wù)之后釋放占用的資源
- 中斷事務(wù)：參與者在完成事務(wù)回滾之后，向協(xié)調(diào)者發(fā)送 Ack 消息，協(xié)調(diào)者接收到事務(wù)參與者的 Ack 消息之后，完成事務(wù)中斷
2PC 優(yōu)缺點
- 2PC 提交將事務(wù)的處理過程分為了投票和執(zhí)行兩個階段，核心思想就是對每個事務(wù)都采用先嘗試后提交的方式處理。2PC 優(yōu)點顯而易見，那就是 原理簡單，實現(xiàn)方便。簡單也意味著很多地方不能盡善盡美，這里梳理三個比較核心的缺陷
- 同步阻塞：無論是在第一階段的過程中，還是在第二階段，所有的參與者資源和協(xié)調(diào)者資源都是被鎖住的，只有當所有節(jié)點準備完畢，事務(wù)協(xié)調(diào)者才會通知進行全局提交，參與者進行本地事務(wù)提交后才會釋放資源。這樣的過程會比較漫長，對性能影響比較大
- 單點故障：如果協(xié)調(diào)者出現(xiàn)問題，那么整個二階段提交流程將無法運轉(zhuǎn)。另外，如果協(xié)調(diào)者是在第二階段出現(xiàn)了故障，那么其它參與者將會處于鎖定事務(wù)資源的狀態(tài)中
數(shù)據(jù)不一致性：當協(xié)調(diào)者在第二階段向所有參與者發(fā)送 Commit 請求后，發(fā)生了局部網(wǎng)絡(luò)異?；蛘邊f(xié)調(diào)者在尚未發(fā)送完 Commit 請求之前自身發(fā)生了崩潰，導致只有部分參與者接收到 Commit 請求，那么接收到的參與者就會進行提交事務(wù)，進而形成了數(shù)據(jù)不一致性
由于 2PC 的簡單方便，所以會產(chǎn)生上述的同步阻塞、單點故障、數(shù)據(jù)不一致等情況，所以在 2PC 的基礎(chǔ)上做了改進，推行出了三階段提交(3PC)
使用 2PC 存在諸多限制，首先就是數(shù)據(jù)庫需要支持 XA 規(guī)范，而且性能與數(shù)據(jù)一致性數(shù)據(jù)均不友好，所以 Seata 中雖然支持 XA 模式，但是主推的還是 AT 模式
3PC 一致性算法
三階段提交(3PC)是二階段提交(2PC)的一個改良版本，引入了兩個新的特性
- 協(xié)調(diào)者和參與者均引入超時機制，通過超時機制來解決 2PC 的同步阻塞問題，避免事務(wù)資源被永久鎖定
- 把二階段演變?yōu)槿A段，二階段提交協(xié)議中的第一階段"準備階段"一分為二，形成了新的 CanCommit、PreCommit、do Commit 三個階段組成事務(wù)處理協(xié)議
這里將不再贅述 3PC 的詳細提交過程，3PC 相比較于 2PC 最大的優(yōu)點就是降低了參與者的阻塞范圍，并且能夠在協(xié)調(diào)者出現(xiàn)單點故障后繼續(xù)達成一致
雖然通過超時機制解決了資源永久阻塞的問題，但是 3PC 依然存在數(shù)據(jù)不一致的問題。當參與者接收到 PreCommit 消息后，如果網(wǎng)絡(luò)出現(xiàn)分區(qū)，此時協(xié)調(diào)者與參與者無法進行正常通信，這種情況下，參與者依然會進行事務(wù)的提交
通過了解 2PC 和 3PC 之后，我們可以知道這兩者都無法徹底解決分布式下的數(shù)據(jù)一致性
JDBC 操作 MySQL XA 事務(wù)
MySQL 從 5.0.3 開始支持 XA 分布式事務(wù)，且只有 InnoDB 存儲引擎支持。MySQL Connector/J 從5.0.0 版本之后開始直接提供對 XA 的支持
在 DTP 模型中，MySQL 屬于 RM 資源管理器，所以這里就不再演示 MySQL 支持 XA 事務(wù)的語句，因為它執(zhí)行的只是自己單一事務(wù)分支，我們通過 JDBC 來演示如何通過 TM 來控制多個 RM 完成 2PC 分布式事務(wù)
這里先來說明需要引入 GAV 的 Maven 版本，因為高版本 8.x 移除了對 XA 分布式事務(wù)的支持(可能也是覺得沒人會用吧)
mysql mysql-connector-java 5.1.38
這里為了保證在公眾號閱讀的舒適性，通過 IDEA 將多行代碼合并為一行了，如果小伙伴需要粘貼到 IDEA 中，格式化一下就好了
因為 XA 協(xié)議的基礎(chǔ)是 2PC 一致性算法，所以小伙伴在看代碼時可以對照上面文章講的 DTP 模型和 2PC 來進行理解以及模擬錯誤和執(zhí)行結(jié)果
- import com.mysql.jdbc.jdbc2.optional.MysqlXAConnection;import com.mysql.jdbc.jdbc2.optional.MysqlXid;import javax.sql.XAConnection;import javax.transaction.xa.XAException;import javax.transaction.xa.XAResource;import javax.transaction.xa.Xid;import java.sql.*;
- public class MysqlXAConnectionTest {
- public static void main(String[] args) throws SQLException {
- // true 表示打印 XA 語句, 用于調(diào)試
- boolean logXaCommands = true;
- // 獲得資源管理器操作接口實例 RM1
- Connection conn1 = DriverManager.getConnection("jdbc:mysql://localhost:3306/test", "root", "root");XAConnection xaConn1 = new MysqlXAConnection((com.mysql.jdbc.Connection) conn1, logXaCommands);XAResource rm1 = xaConn1.getXAResource();
- // 獲得資源管理器操作接口實例 RM2
- Connection conn2 = DriverManager.getConnection("jdbc:mysql://localhost:3306/test", "root", "root");XAConnection xaConn2 = new MysqlXAConnection((com.mysql.jdbc.Connection) conn2, logXaCommands);XAResource rm2 = xaConn2.getXAResource();
- // AP（應(yīng)用程序）請求 TM（事務(wù)管理器） 執(zhí)行一個分布式事務(wù), TM 生成全局事務(wù) ID
- byte[] gtrid = "distributed_transaction_id_1".getBytes();int formatId = 1;
- try {
- // ============== 分別執(zhí)行 RM1 和 RM2 上的事務(wù)分支 ====================
- // TM 生成 RM1 上的事務(wù)分支 ID
- byte[] bqual1 = "transaction_001".getBytes();Xid xid1 = new MysqlXid(gtrid, bqual1, formatId);
- // 執(zhí)行 RM1 上的事務(wù)分支
- rm1.start(xid1, XAResource.TMNOFLAGS);PreparedStatement ps1 = conn1.prepareStatement("INSERT into user(name) VALUES ('jack')");ps1.execute();rm1.end(xid1, XAResource.TMSUCCESS);
- // TM 生成 RM2 上的事務(wù)分支 ID
- byte[] bqual2 = "transaction_002".getBytes();Xid xid2 = new MysqlXid(gtrid, bqual2, formatId);
- // 執(zhí)行 RM2 上的事務(wù)分支
- rm2.start(xid2, XAResource.TMNOFLAGS);PreparedStatement ps2 = conn2.prepareStatement("INSERT into user(name) VALUES ('rose')");ps2.execute();rm2.end(xid2, XAResource.TMSUCCESS);
- // =================== 兩階段提交 ================================
- // phase1: 詢問所有的RM 準備提交事務(wù)分支
- int rm1_prepare = rm1.prepare(xid1);int rm2_prepare = rm2.prepare(xid2);
- // phase2: 提交所有事務(wù)分支
- if (rm1_prepare == XAResource.XA_OK && rm2_prepare == XAResource.XA_OK) {
- // 所有事務(wù)分支都 prepare 成功, 提交所有事務(wù)分支
- rm1.commit(xid1, false);rm2.commit(xid2, false);
- } else {
- // 如果有事務(wù)分支沒有成功, 則回滾
- rm1.rollback(xid1);rm1.rollback(xid2);
- }
- } catch (XAException e) { e.printStackTrace(); } }}
結(jié)言
本文通過圖文并茂的方式講解了如何保證本地事務(wù)的四大特性，分布式事務(wù)的產(chǎn)出背景，以及 2PC、3PC 為何不能解決分布式情況下的數(shù)據(jù)一致性，最后通過 JDBC 演示了 2PC 的執(zhí)行流程。相信大家看過后也對分布式事務(wù)有了較深的印象，同時對 DTP、XA、2PC 這幾種比較容易混淆的概念有了清楚的認識。
這是《分布式事務(wù)》專欄的第一章開篇，后面陸續(xù)完成通過消息中間件、可靠消息模型、Seata XA模型完成分布式事務(wù)的文章，并對不同的實現(xiàn)方式進行總結(jié)利弊，挑選出合適場景使用不同的分布式事務(wù)解決方案。
作者認為最好的學習方式那就是實戰(zhàn)，如果沒有接觸過分布式事務(wù)的小伙伴，可以通過自己正在寫的項目，模擬出分布式事務(wù)的業(yè)務(wù)場景，加深印象的同時也能夠更好理解分布式事務(wù)解決方案相關(guān)設(shè)計思路。
網(wǎng)站名稱：徹底掌握分布式事務(wù)2PC、3PC模型
本文鏈接：http://fisionsoft.com.cn/article/cosijhh.html
