[[385682]]

本文轉(zhuǎn)載自微信公眾號(hào)「源碼興趣圈」，作者馬龍臺(tái)。轉(zhuǎn)載本文請(qǐng)聯(lián)系源碼興趣圈公眾號(hào)。  

工作中使用最多的是本地事務(wù)，但是在對(duì)單一項(xiàng)目拆分為 SOA、微服務(wù)之后，就會(huì)牽扯出分布式事務(wù)場(chǎng)景

文章以分布式事務(wù)為主線展開說明，并且針對(duì) 2PC、3PC 算法進(jìn)行詳細(xì)的講解，最后通過一個(gè) Demo 來更深入掌握分布式事務(wù)，文章目錄結(jié)構(gòu)如下

• 什么是事務(wù)
• 什么是分布式事務(wù)
• DTP 模型和 XA 規(guī)范
  • 什么是 DTP 模型
  • 什么是 XA 規(guī)范
• 2PC 一致性算法
  • 2PC-準(zhǔn)備階段
  • 2PC-提交階段
  • 2PC 算法優(yōu)缺點(diǎn)
• 3PC 一致性算法
• JDBC 操作 MySQL XA 事務(wù)
• 結(jié)言

什么是事務(wù)

事務(wù)是數(shù)據(jù)庫操作的最小工作單元，一組不可再分割的操作集合，是作為單個(gè)邏輯工作單元執(zhí)行的一系列操作。這些操作作為一個(gè)整體一起向系統(tǒng)提交，要么都執(zhí)行、要么都不執(zhí)行

事務(wù)具有四個(gè)特征，分別是原子性(Atomicity)、一致性(Consistency)、隔離性(Isolation)和持久性(Durability)，簡(jiǎn)稱為事務(wù)的 ACID 特性

如何保證事務(wù)的 ACID 特性?

• 原子性(Atomicity)：事務(wù)內(nèi) SQL 要么同時(shí)成功要么同時(shí)失敗，基于撤銷日志(undo 日志)實(shí)現(xiàn)
• 一致性(Consistency)：系統(tǒng)從一個(gè)正確態(tài)轉(zhuǎn)移到另一個(gè)正確態(tài)，由應(yīng)用通過 AID 來保證，可以說是事務(wù)的核心特性
• 隔離性(Isolation)：控制事務(wù)并發(fā)執(zhí)行時(shí)數(shù)據(jù)的可見性，基于鎖和多版本并發(fā)控制(mvcc)實(shí)現(xiàn)
• 持久性(Durability)：提交后一定存儲(chǔ)成功不會(huì)丟失，基于重做日志(redo log)實(shí)現(xiàn)

文章主要是介紹分布式事務(wù) 2PC 和 3PC，關(guān)于 redo、undo 日志、mvcc、鎖這塊的內(nèi)容后續(xù)再詳細(xì)介紹

在早些時(shí)候，我們應(yīng)用程序還是單體項(xiàng)目，所以操作的都是單一數(shù)據(jù)庫，這種情況下我們稱之為本地事務(wù)。本地事務(wù)的 ACID 一般都是由數(shù)據(jù)庫層面支持的，比如我們工作中常用的 MySQL 數(shù)據(jù)庫

平常我們?cè)诓僮?MySQL 客戶端時(shí)，MySQL 會(huì)隱式對(duì)事務(wù)做自動(dòng)提交，所以日常工作不會(huì)涉及手動(dòng)書寫事務(wù)的創(chuàng)建、提交、回滾等操作。如果想要試驗(yàn)鎖、MVCC等特性，可以創(chuàng)建多個(gè)會(huì)話，通過begin、commit、rollback等命令來試驗(yàn)下不同事務(wù)之間的數(shù)據(jù)，看執(zhí)行結(jié)果和自己所想是否一致

我們平常開發(fā)項(xiàng)目代碼時(shí)使用的是 Spring 封裝好的事務(wù)，所以也不會(huì)手動(dòng)編寫對(duì)數(shù)據(jù)庫事務(wù)的提交、回滾等方法(個(gè)別情況除外)。這里使用原生 JDBC 寫一個(gè)示例代碼，幫助大家理解如何通過事務(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è)想一下，每次進(jìn)行數(shù)據(jù)庫操作，都要寫重復(fù)的創(chuàng)建事務(wù)、提交、回滾等方法是不是挺痛苦的，那 Spring 如何自動(dòng)幫助我們管理事務(wù)的呢?Spring 項(xiàng)目中我們一般使用兩種方式來進(jìn)行事務(wù)的管理，編程式事務(wù)和聲明式事務(wù)

項(xiàng)目中使用 Spring 管理事務(wù)，要么在接口方法上添加注解 @Transactional，要么使用 AOP 配置切面事務(wù)。其實(shí)這兩種方式大同小異，只不過 @Transactional 的粒度更細(xì)一些，實(shí)現(xiàn)原理上都是依賴 AOP，舉例說明下

@Service 
public class TransactionalService { 
  @Transactional 
  public void save() { 
      // 業(yè)務(wù)操作 
  } 
} 

TransactionalService 會(huì)被 Spring 創(chuàng)建一個(gè)代理對(duì)象放入到容器中，創(chuàng)建后的代理對(duì)象相當(dā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)異常則進(jìn)行回滾 
      } 
      // 提交事務(wù) 
  } 
} 

示例代碼看著簡(jiǎn)潔明了，但是真正的代碼生成代碼對(duì)比要復(fù)雜很多。關(guān)于事務(wù)管理器，Spring 提供了接口 PlatformTransactionManager，其內(nèi)部包含兩個(gè)重要實(shí)現(xiàn)類

• DataSourceTransactionManager：支持本地事務(wù)，內(nèi)部通過java.sql.Connection來開啟、提交和回滾事務(wù)
• JtaTransactionManager：用于支持分布式事務(wù)，其實(shí)現(xiàn)了 JTA 規(guī)范，使用 XA 協(xié)議進(jìn)行兩階段提交

通過這兩個(gè)實(shí)現(xiàn)類得知，平常我們使用的編程式事務(wù)和聲明式事務(wù)依賴于本地事務(wù)管理實(shí)現(xiàn)，Spring 同時(shí)也支持分布式事務(wù)，關(guān)于 JTA 分布式事務(wù)的支持網(wǎng)上資料挺多的，就不在這里贅述了

什么是分布式事務(wù)

日常業(yè)務(wù)代碼中的本地事務(wù)我們一直都在用，理解起來并不困難。但是隨著服務(wù)化(SOA)、微服務(wù)的流行，平常我們的單一業(yè)務(wù)系統(tǒng)被拆分成為了多個(gè)系統(tǒng)，為了迎合業(yè)務(wù)系統(tǒng)的變更，數(shù)據(jù)庫也結(jié)合業(yè)務(wù)進(jìn)行了拆分

比如以學(xué)校管理系統(tǒng)舉例說明，可能就會(huì)拆分為學(xué)生服務(wù)、課程服務(wù)、老師服務(wù)等，數(shù)據(jù)庫也拆分為多個(gè)庫。當(dāng)這種情況，把不同的服務(wù)部署到服務(wù)器，就會(huì)有可能面臨下述的服務(wù)調(diào)用

ServiceA 服務(wù)需要操作數(shù)據(jù)庫執(zhí)行本地事務(wù)，同時(shí)需要調(diào)用 ServiceB 和 ServiceC 服務(wù)發(fā)起事務(wù)調(diào)用，如何保證三個(gè)服務(wù)的事務(wù)要么一起成功或者一起失敗，如何保證用戶發(fā)起請(qǐng)求的事務(wù) ACID 特性呢?無疑這就是分布式事務(wù)場(chǎng)景，三個(gè)服務(wù)的單一本地事務(wù)都無法保證整個(gè)請(qǐng)求的事務(wù)

分布式事務(wù)場(chǎng)景有很多種解決方案，以不同分類來看，強(qiáng)一致性解決方案、最終一致性解決方案，細(xì)分其中的方案包括2PC、3PC、TCC、可靠消息...

業(yè)界中使用較多的像阿里的 RocketMQ 事務(wù)消息、Seata XA模式、可靠消息模型這幾種解決方案。不過，分布式事務(wù)無一例外都是會(huì)直接或間接操作多個(gè)數(shù)據(jù)庫，而且使用了分布式事務(wù)同時(shí)也會(huì)帶來新的挑戰(zhàn)，那就是性能問題。如果為了保證強(qiáng)一致性分布式事務(wù)亦或者補(bǔ)償方案的最終一致性，導(dǎo)致了性能的下降，對(duì)于正常業(yè)務(wù)而言，無疑是得不償失的

DTP 模型和 XA 規(guī)范

X/Open 組織定義了分布式事務(wù)的模型(DTP)和 分布式事務(wù)協(xié)議(XA)，DTP 由以下幾個(gè)模型元素組成

• AP(Application 應(yīng)用程序)：用于定義事務(wù)邊界(即定義事務(wù)的開始和結(jié)束)，并且在事務(wù)邊界內(nèi)對(duì)資源進(jìn)行操作
• TM(Transaction Manager 事務(wù)管理器)：負(fù)責(zé)分配事務(wù)唯一標(biāo)識(shí)，監(jiān)控事務(wù)的執(zhí)行進(jìn)度，并負(fù)責(zé)事務(wù)的提交、回滾等
• RM(Resource Manager 資源管理器)：如數(shù)據(jù)庫、文件系統(tǒng)等，并提供訪問資源的方式
• CRM(Communication Resource Manager 通信資源管理器)：控制一個(gè)TM域(TM domain)內(nèi)或者跨TM域的分布式應(yīng)用之間的通信
• CP(Communication Protocol 通信協(xié)議)：提供CRM提供的分布式應(yīng)用節(jié)點(diǎn)之間的底層通信服務(wù)

在 DTP 分布式事務(wù)模型中，基本組成需要涵蓋 AP、TM、RMS(不需要 CRM、CP 也是可以的)，如下圖所示

XA 規(guī)范

XA 規(guī)范最重要的作用就是定義 RM(資源管理器)與 TM(事務(wù)管理器)之間的交互接口。另外，XA 規(guī)范除了定義 2PC 之間的交互接口外，同時(shí)對(duì) 2PC 進(jìn)行了優(yōu)化

梳理下 DTP、XA、2PC 之間的關(guān)系

DTP 規(guī)定了分布式事務(wù)中的角色模型，并在其中指定了全局事務(wù)的控制需要使用 2PC 協(xié)議來保證數(shù)據(jù)的一致性

2PC 是 Two-Phase Commit 的縮寫，即二階段提交，是計(jì)算機(jī)網(wǎng)絡(luò)尤其是數(shù)據(jù)庫領(lǐng)域內(nèi)，為了保證分布式系統(tǒng)架構(gòu)下所有節(jié)點(diǎn)在進(jìn)行事務(wù)處理過程中能夠保證原子性和一致性而設(shè)計(jì)的一種算法。同時(shí)，2PC 也被認(rèn)為是一種一致性協(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 一致性算法

當(dāng)應(yīng)用程序(AP)發(fā)起一個(gè)事務(wù)操作需要跨越多個(gè)分布式節(jié)點(diǎn)的時(shí)候，每一個(gè)分布式節(jié)點(diǎn)(RM)知道自己進(jìn)行事務(wù)操作的結(jié)果是成功或是失敗，但是卻不能獲取到其它分布式節(jié)點(diǎn)的操作結(jié)果。為了保證事務(wù)處理的 ACID 特性，就需要引入稱為"協(xié)調(diào)者"的組件(TM)來進(jìn)行統(tǒng)一調(diào)度分布式的執(zhí)行邏輯

協(xié)調(diào)者負(fù)責(zé)調(diào)度參與整體事務(wù)的分布式節(jié)點(diǎn)的行為，并最終決定這些分布式節(jié)點(diǎn)要把事務(wù)進(jìn)行提交還是回滾。所以，基于這種思想下，衍生出了二階段提交和三階段提交兩種分布式一致性算法協(xié)議。二階段指的是準(zhǔn)備階段和提交階段，下面我們先看準(zhǔn)備階段都做了什么事情

2PC-準(zhǔn)備階段

二階段提交中第一階段也叫做"投票階段"，即各參與者投票表明自身是否繼續(xù)執(zhí)行接下來的事務(wù)提交步驟

• 事務(wù)詢問：協(xié)調(diào)者向所有參與本次分布式事務(wù)的參與者發(fā)送事務(wù)內(nèi)容，詢問是否可以執(zhí)行事務(wù)提交操作，然后開始等待各個(gè)參與者的響應(yīng)
• 執(zhí)行事務(wù)：參與者收到協(xié)調(diào)者的事務(wù)請(qǐng)求，執(zhí)行對(duì)應(yīng)的事務(wù)，并將內(nèi)容寫入 Undo 和 Redo 日志
• 返回響應(yīng)：如果各個(gè)參與者執(zhí)行了事務(wù)，那么反饋協(xié)調(diào)者 Yes 響應(yīng);如果各個(gè)參與者沒有能夠成功執(zhí)行事務(wù)，那么就會(huì)返回協(xié)調(diào)者 No 響應(yīng)

如果第一階段全部參與者返回成功響應(yīng)，那么進(jìn)入事務(wù)提交步驟，反之本次分布式事務(wù)以失敗返回。以 MySQL 數(shù)據(jù)庫為例，在第一階段，事務(wù)管理器(TM)向所有涉及到的數(shù)據(jù)庫(RM)發(fā)出 prepare(準(zhǔn)備提交) 請(qǐng)求，數(shù)據(jù)庫收到請(qǐng)求后執(zhí)行數(shù)據(jù)修改和日志記錄處理，處理完成后把事務(wù)的狀態(tài)修改為 "可提交"，最終將結(jié)果返回給事務(wù)處理器

2PC-提交階段

提交階段分為兩個(gè)流程，一個(gè)是各參與者正常執(zhí)行事務(wù)提交流程，并返回 Yes 響應(yīng)，表示各參與者投票執(zhí)行成功;一個(gè)是各參與者當(dāng)中有執(zhí)行失敗返回 No 響應(yīng)或超時(shí)情況，將觸發(fā)全局回滾，表示分布式事務(wù)執(zhí)行失敗

• 執(zhí)行事務(wù)提交
• 中斷事務(wù)

執(zhí)行事務(wù)提交

假設(shè)協(xié)調(diào)者從所有的參與者獲得的反饋都是 Yes 響應(yīng)，那么就會(huì)執(zhí)行事務(wù)提交操作

• 事務(wù)提交：協(xié)調(diào)者向所有參與者節(jié)點(diǎn)發(fā)出 Commit 請(qǐng)求，各個(gè)參與者接收到 Commit 請(qǐng)求后，將本地事務(wù)進(jìn)行提交操作，并在完成提交之后釋放事務(wù)執(zhí)行周期內(nèi)占用的事務(wù)資源
• 完成事務(wù)：各個(gè)參與者完成事務(wù)提交之后，向協(xié)調(diào)者發(fā)送 Ack 響應(yīng)，協(xié)調(diào)者接收到響應(yīng)后完成本次分布式事務(wù)

中斷事務(wù)

假設(shè)任意一個(gè)事務(wù)參與者節(jié)點(diǎn)向協(xié)調(diào)者反饋了 No 響應(yīng)(注意這里的 No 響應(yīng)指的是第一階段)，或者在等待超時(shí)之后，協(xié)調(diào)者沒有接到所有參與者的反饋響應(yīng)，那么就會(huì)進(jìn)行事務(wù)中斷流程

• 事務(wù)回滾：協(xié)調(diào)者向所有參與者發(fā)出 Rollback 請(qǐng)求，參與者接收到回滾請(qǐng)求后，使用第一階段寫入的 undo log 執(zhí)行事務(wù)的回滾，并在完成回滾事務(wù)之后釋放占用的資源
• 中斷事務(wù)：參與者在完成事務(wù)回滾之后，向協(xié)調(diào)者發(fā)送 Ack 消息，協(xié)調(diào)者接收到事務(wù)參與者的 Ack 消息之后，完成事務(wù)中斷

2PC 優(yōu)缺點(diǎn)

1. 2PC 提交將事務(wù)的處理過程分為了投票和執(zhí)行兩個(gè)階段，核心思想就是對(duì)每個(gè)事務(wù)都采用先嘗試后提交的方式處理。2PC 優(yōu)點(diǎn)顯而易見，那就是 原理簡(jiǎn)單，實(shí)現(xiàn)方便。簡(jiǎn)單也意味著很多地方不能盡善盡美，這里梳理三個(gè)比較核心的缺陷
2. 同步阻塞：無論是在第一階段的過程中，還是在第二階段，所有的參與者資源和協(xié)調(diào)者資源都是被鎖住的，只有當(dāng)所有節(jié)點(diǎn)準(zhǔn)備完畢，事務(wù)協(xié)調(diào)者才會(huì)通知進(jìn)行全局提交，參與者進(jìn)行本地事務(wù)提交后才會(huì)釋放資源。這樣的過程會(huì)比較漫長(zhǎng)，對(duì)性能影響比較大
3. 單點(diǎn)故障：如果協(xié)調(diào)者出現(xiàn)問題，那么整個(gè)二階段提交流程將無法運(yùn)轉(zhuǎn)。另外，如果協(xié)調(diào)者是在第二階段出現(xiàn)了故障，那么其它參與者將會(huì)處于鎖定事務(wù)資源的狀態(tài)中

數(shù)據(jù)不一致性：當(dāng)協(xié)調(diào)者在第二階段向所有參與者發(fā)送 Commit 請(qǐng)求后，發(fā)生了局部網(wǎng)絡(luò)異?；蛘邊f(xié)調(diào)者在尚未發(fā)送完 Commit 請(qǐng)求之前自身發(fā)生了崩潰，導(dǎo)致只有部分參與者接收到 Commit 請(qǐng)求，那么接收到的參與者就會(huì)進(jìn)行提交事務(wù)，進(jìn)而形成了數(shù)據(jù)不一致性

由于 2PC 的簡(jiǎn)單方便，所以會(huì)產(chǎn)生上述的同步阻塞、單點(diǎn)故障、數(shù)據(jù)不一致等情況，所以在 2PC 的基礎(chǔ)上做了改進(jìn)，推行出了三階段提交(3PC)

使用 2PC 存在諸多限制，首先就是數(shù)據(jù)庫需要支持 XA 規(guī)范，而且性能與數(shù)據(jù)一致性數(shù)據(jù)均不友好，所以 Seata 中雖然支持 XA 模式，但是主推的還是 AT 模式

3PC 一致性算法

三階段提交(3PC)是二階段提交(2PC)的一個(gè)改良版本，引入了兩個(gè)新的特性

1. 協(xié)調(diào)者和參與者均引入超時(shí)機(jī)制，通過超時(shí)機(jī)制來解決 2PC 的同步阻塞問題，避免事務(wù)資源被永久鎖定
2. 把二階段演變?yōu)槿A段，二階段提交協(xié)議中的第一階段"準(zhǔn)備階段"一分為二，形成了新的 CanCommit、PreCommit、do Commit 三個(gè)階段組成事務(wù)處理協(xié)議
   

這里將不再贅述 3PC 的詳細(xì)提交過程，3PC 相比較于 2PC 最大的優(yōu)點(diǎn)就是降低了參與者的阻塞范圍，并且能夠在協(xié)調(diào)者出現(xiàn)單點(diǎn)故障后繼續(xù)達(dá)成一致

雖然通過超時(shí)機(jī)制解決了資源永久阻塞的問題，但是 3PC 依然存在數(shù)據(jù)不一致的問題。當(dāng)參與者接收到 PreCommit 消息后，如果網(wǎng)絡(luò)出現(xiàn)分區(qū)，此時(shí)協(xié)調(diào)者與參與者無法進(jìn)行正常通信，這種情況下，參與者依然會(huì)進(jìn)行事務(wù)的提交

通過了解 2PC 和 3PC 之后，我們可以知道這兩者都無法徹底解決分布式下的數(shù)據(jù)一致性

JDBC 操作 MySQL XA 事務(wù)

MySQL 從 5.0.3 開始支持 XA 分布式事務(wù)，且只有 InnoDB 存儲(chǔ)引擎支持。MySQL Connector/J 從5.0.0 版本之后開始直接提供對(duì) XA 的支持

在 DTP 模型中，MySQL 屬于 RM 資源管理器，所以這里就不再演示 MySQL 支持 XA 事務(wù)的語句，因?yàn)樗鼒?zhí)行的只是自己?jiǎn)我皇聞?wù)分支，我們通過 JDBC 來演示如何通過 TM 來控制多個(gè) RM 完成 2PC 分布式事務(wù)

這里先來說明需要引入 GAV 的 Maven 版本，因?yàn)楦甙姹?8.x 移除了對(duì) XA 分布式事務(wù)的支持(可能也是覺得沒人會(huì)用吧)

<dependencies> 
    <!-- https://mvnrepository.com/artifact/mysql/mysql-connector-java --> 
    <dependency> 
        <groupId>mysql</groupId> 
        <artifactId>mysql-connector-java</artifactId> 
        <version>5.1.38</version> 
    </dependency> 
</dependencies> 

這里為了保證在公眾號(hào)閱讀的舒適性，通過 IDEA 將多行代碼合并為一行了，如果小伙伴需要粘貼到 IDEA 中，格式化一下就好了

因?yàn)?XA 協(xié)議的基礎(chǔ)是 2PC 一致性算法，所以小伙伴在看代碼時(shí)可以對(duì)照上面文章講的 DTP 模型和 2PC 來進(jìn)行理解以及模擬錯(cuò)誤和執(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; 
        // 獲得資源管理器操作接口實(shí)例 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(); 
        // 獲得資源管理器操作接口實(shí)例 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)用程序）請(qǐng)求 TM（事務(wù)管理器） 執(zhí)行一個(gè)分布式事務(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 準(zhǔn)備提交事務(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í)行流程。相信大家看過后也對(duì)分布式事務(wù)有了較深的印象，同時(shí)對(duì) DTP、XA、2PC 這幾種比較容易混淆的概念有了清楚的認(rèn)識(shí)。

這是《分布式事務(wù)》專欄的第一章開篇，后面陸續(xù)完成通過消息中間件、可靠消息模型、Seata XA模型完成分布式事務(wù)的文章，并對(duì)不同的實(shí)現(xiàn)方式進(jìn)行總結(jié)利弊，挑選出合適場(chǎng)景使用不同的分布式事務(wù)解決方案。

作者認(rèn)為最好的學(xué)習(xí)方式那就是實(shí)戰(zhàn)，如果沒有接觸過分布式事務(wù)的小伙伴，可以通過自己正在寫的項(xiàng)目，模擬出分布式事務(wù)的業(yè)務(wù)場(chǎng)景，加深印象的同時(shí)也能夠更好理解分布式事務(wù)解決方案相關(guān)設(shè)計(jì)思路。