如何使用分布式事務(wù)2PC、3PC模型

本篇內(nèi)容主要講解“如何使用分布式事務(wù)2PC、3PC模型”，感興趣的朋友不妨來(lái)看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強(qiáng)。下面就讓小編來(lái)帶大家學(xué)習(xí)“如何使用分布式事務(wù)2PC、3PC模型”吧!

什么是事務(wù)

事務(wù)是數(shù)據(jù)庫(kù)操作的最小工作單元，一組不可再分割的操作集合，是作為單個(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 來(lái)保證，可以說是事務(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ù)庫(kù)，這種情況下我們稱之為本地事務(wù)。本地事務(wù)的 ACID  一般都是由數(shù)據(jù)庫(kù)層面支持的，比如我們工作中常用的 MySQL 數(shù)據(jù)庫(kù)

平常我們?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等命令來(lái)試驗(yàn)下不同事務(wù)之間的數(shù)據(jù)，看執(zhí)行結(jié)果和自己所想是否一致

我們平常開發(fā)項(xiàng)目代碼時(shí)使用的是 Spring 封裝好的事務(wù)，所以也不會(huì)手動(dòng)編寫對(duì)數(shù)據(jù)庫(kù)事務(wù)的提交、回滾等方法(個(gè)別情況除外)。這里使用原生 JDBC  寫一個(gè)示例代碼，幫助大家理解如何通過事務(wù)保證 ACID 四大特性

Connection conn = ...; // 獲取數(shù)據(jù)庫(kù)連接 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ù)庫(kù)操作，都要寫重復(fù)的創(chuàng)建事務(wù)、提交、回滾等方法是不是挺痛苦的，那 Spring 如何自動(dòng)幫助我們管理事務(wù)的呢?Spring  項(xiàng)目中我們一般使用兩種方式來(lái)進(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來(lái)開啟、提交和回滾事務(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ù)我們一直都在用，理解起來(lái)并不困難。但是隨著服務(wù)化(SOA)、微服務(wù)的流行，平常我們的單一業(yè)務(wù)系統(tǒng)被拆分成為了多個(gè)系統(tǒng)，為了迎合業(yè)務(wù)系統(tǒng)的變更，數(shù)據(jù)庫(kù)也結(jié)合業(yè)務(wù)進(jìn)行了拆分

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

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

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

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

2PC 是 Two-Phase Commit  的縮寫，即二階段提交，是計(jì)算機(jī)網(wǎng)絡(luò)尤其是數(shù)據(jù)庫(kù)領(lǐng)域內(nèi)，為了保證分布式系統(tǒng)架構(gòu)下所有節(jié)點(diǎn)在進(jìn)行事務(wù)處理過程中能夠保證原子性和一致性而設(shè)計(jì)的一種算法。同時(shí)，2PC  也被認(rèn)為是一種一致性協(xié)議，用來(lái)保證分布式系統(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ù)庫(kù)(比如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)來(lái)進(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í)行接下來(lái)的事務(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ù)庫(kù)為例，在第一階段，事務(wù)管理器(TM)向所有涉及到的數(shù)據(jù)庫(kù)(RM)發(fā)出 prepare(準(zhǔn)備提交)  請(qǐng)求，數(shù)據(jù)庫(kù)收到請(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)者沒有接到所有參與者的反饋?lái)憫?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. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2. 2PC 提交將事務(wù)的處理過程分為了投票和執(zhí)行兩個(gè)階段，核心思想就是對(duì)每個(gè)事務(wù)都采用先嘗試后提交的方式處理。2PC 優(yōu)點(diǎn)顯而易見，那就是  原理簡(jiǎn)單，實(shí)現(xiàn)方便。簡(jiǎn)單也意味著很多地方不能盡善盡美，這里梳理三個(gè)比較核心的缺陷

3. 同步阻塞：無(wú)論是在第一階段的過程中，還是在第二階段，所有的參與者資源和協(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ì)性能影響比較大

4. 單點(diǎn)故障：如果協(xié)調(diào)者出現(xiàn)問題，那么整個(gè)二階段提交流程將無(wú)法運(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ù)庫(kù)需要支持 XA 規(guī)范，而且性能與數(shù)據(jù)一致性數(shù)據(jù)均不友好，所以 Seata 中雖然支持 XA 模式，但是主推的還是  AT 模式

3PC 一致性算法

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

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2. 協(xié)調(diào)者和參與者均引入超時(shí)機(jī)制，通過超時(shí)機(jī)制來(lái)解決 2PC 的同步阻塞問題，避免事務(wù)資源被永久鎖定

3. 把二階段演變?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)者與參與者無(wú)法進(jìn)行正常通信，這種情況下，參與者依然會(huì)進(jìn)行事務(wù)的提交

通過了解 2PC 和 3PC 之后，我們可以知道這兩者都無(wú)法徹底解決分布式下的數(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ǔ)句，因?yàn)樗鼒?zhí)行的只是自己?jiǎn)我皇聞?wù)分支，我們通過  JDBC 來(lái)演示如何通過 TM 來(lái)控制多個(gè) RM 完成 2PC 分布式事務(wù)

這里先來(lái)說明需要引入 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 來(lái)進(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 語(yǔ)句, 用于調(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(); } }}

到此，相信大家對(duì)“如何使用分布式事務(wù)2PC、3PC模型”有了更深的了解，不妨來(lái)實(shí)際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！