分布式事务之2PC、3PC、TCC

最新推荐文章于 2025-06-23 15:21:30 发布
原创 最新推荐文章于 2025-06-23 15:21:30 发布 · 1.6k 阅读 · 1 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

本文介绍了分布式事务中的2PC、3PC和TCC三种协议。2PC分为准备和提交两个阶段，但在某些情况下可能导致数据不一致。3PC在2PC基础上增加了一个CanCommit阶段，提高了可用性。TCC则要求每个分支事务实现Try、Confirm、Cancel三个操作，对业务侵入性强，但允许更细粒度的数据操作控制。

目录

什么是2PC

关系型数据库的2PC=>XA方案

分布式事务框架Seata的2PC=》AT方案

Seata的2PC和传统2PC比较

2PC的问题

什么是3PC

什么是TCC

 

什么是2PC

 

2PC即两阶段提交协议，将整个事务流程分为两个阶段：准备阶段、提交阶段。

简单来说准备阶段就执行事务代码，但不一定提交，提交阶段决定是最终提交事务还是回滚事务。

为什么要简单来说？因为基于数据库的2PC和分布式框架Seata的2PC有差异，不能一概而论。

 

 

关系型数据库的2PC=>XA方案

 

数据库的2PC也叫传统2PC，是2PC在数据库层面的实现，也叫做XA方案。

XA方案由三部分组成：应用程序、事务管理器和参与者。 具体的事务执行过程如下

准备阶段(Prepare phase)：

事务管理器给每个参与者发送Prepare消息，每个数据库参与者在本地执行事务，并写本地Undo/Redo日志，此时事务没有提交

提交阶段(Commit pha

最低0.47元/天 解锁文章
分布式事务讲解 - 2PC、3PC、TCC
m0_63164811的博客
01-18 1205
分布式事务讲解 - 2PC、3PC、TCC
2pc和3pc和tcc
m0_59662444的博客
10-16 313
2pc缺点： 性能问题。从流程上我们可以看得出，其最大缺点就在于它的执行过程中间，节点都处于阻塞状态。各个操作数据库的节点此时都占用着数据库资源，只有当所有节点准备完毕，事务协调者才会通知进行全局提交，参与者进行本地事务提交后才会释放资源。这样的过程会比较漫长，对性能影响比较大 协调者单点故障问题。事务协调者是整个XA模型的核心，一旦事务协调者节点挂掉，会导致参与者收不到提交或回滚的通知，从而导致参与者节点始终处于事务无法完成的中间状态 丢失消息导致的数据不一致问题。在第二个阶段，
分布式事务（2PC/3PC/TCC 最终一致性详解）
马小婧QAQ
02-25 1219
在分布式系统中，我们一般会根据业务对服务进行划分，这就会存在一些服务间的调用关系，所以普通的本地事务是满足不了我们的要求了，需要引入分布式事务来实现我们的一致性的要求。 这里对事务进行一个简单的介绍： 同学A给同学B转250块钱，系统首先从同学A的银行卡扣除250块钱，如果上述这个步骤成功了，但是系统往同学B的银行卡上转250块钱的时候失败了，那么就会造成数据对不上的情况了。在这种情况下我们就需要引入事务，保证转钱这两步操作要么同时成功要么同时失败，成功的情况就是同学B银行卡也收到了钱，失败的情况是回滚
2PC、3PC、TCC
a001807的博客
03-15 1891
导语：看完《软件架构设计-大型网站技术架构与业务架构融合之道》这本书之后，一股脑灌到脑子里很多关于事务一致性的概念，比如说2PC、TCC。但是似乎只是留下了一个模糊的印象，对他们使用的场景，有什么区别没有清晰的概念，所以想借这篇文章，捋捋清楚。 数据库事务 对于数据库来说，事务就是一个“代码块”，这个代码块要么不执行，要么全部执行，事务要操作数据（数据库里的表），事务与事务之间会存在并发冲突，就好比在多线程编程中，不同的线程操作同一份数据，存在线程间的并发是一个道理。 数据库事务的四个特性ACID： Ato
跟我学分布式事务之2PC和3PC
小程故事多
12-07 2445
分布式一致性回顾 在分布式系统中，为了保证数据的高可用，通常，我们会将数据保留多个副本(replica)，这些副本会放置在不同的物理的机器上。为了对用户提供正确的增\删\改\差等语义，我们需要保证这些放置在不同物理机器上的副本是一致的。 为了解决这种分布式一致性问题，前人在性能和数据一致性的反反复复权衡过程中总结了许多典型的协议和算法。其中比较著名的有二阶提交协议（Two Phase Com...
分布式系统设计之分布式事务（2PC、3PC、TCC、Saga）
DKPT的博客
04-03 1320
2PC通过协调者（Coordinator）与参与者（Participant）协作，将事务提交分为两个阶段：在2PC基础上增加预提交阶段，减少阻塞时间：通过业务层实现补偿机制，将事务拆分为三个阶段：将长事务拆分为多个本地短事务链，通过正向执行与反向补偿实现最终一致性：
【分布式微服务云原生】掌握Java分布式事务：2PC、3PC、TCC与Seata全解析
Dylaniou的博客
10-09 2198
在现代互联网应用中，分布式事务是确保数据一致性的关键技术。本文深入探讨了分布式事务的核心技术，包括两阶段提交（2PC）、三阶段提交（3PC）、TCC（Try-Confirm-Cancel）以及Seata。读者将能够理解这些技术的原理、优缺点以及在实际项目中的应用。
分布式事务：2PC与3PC
最新发布
Quan
06-23 851
2PC和3PC是两种经典的分布式事务协议。2PC采用两阶段提交(准备+提交)，优点是简单易实现，但存在同步阻塞、单点故障和数据不一致风险。3PC在2PC基础上增加预提交阶段和超时机制，降低了阻塞范围和单点故障影响，但增加了复杂度和网络开销。实际应用中，2PC多见于MySQL XA等技术，3PC因复杂性应用较少。现代系统更倾向于采用TCC、SAGA等柔性事务方案来规避两者的固有缺陷，实现更好的分布式事务处理效果。
分布式事务 3PC
激流丶的博客
06-06 798
3PC（Three-Phase Commit）是一种增强型的2PC（Two-Phase Commit）协议，用于解决2PC协议存在的可靠性问题和性能问题。3PC协议将2PC协议的两个阶段分为了三个阶段，同时引入了超时机制，从而提高了协议的可靠性和容错性。
分布式事务讲解之CAP，2PC，3PC，TCC，分布式锁
上善若泪
03-31 5371
是两阶段提交的一个变种，针对每个操作，都需要有一个其对应的确认和取消操作，当操作成功时调用确认操作，当操作失败时调用取消操作，类似于二阶段提交，只不过是这里的提交和回滚是针对业务上的，所以基于TCC实现的分布式事务也可以看做是对业务的一种补偿机制，其核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作。try阶段：尝试去执行，完成所有业务的一致性检查，预留必须的业务资源。Confirm阶段：确认执行业务，如果Try阶段执行成功，接着执行Confirm 阶段。
【分布式】分布式事务基础概念（2PC，3PC，TCC）
BookSea的博客
04-23 3361
文章目录XA协议两阶段提交协议（2PC）2PC 过程准备阶段提交阶段2PC总结三阶段提交协议（3PC）3PC过程阶段一 CanCommit阶段二 PreCommit阶段三 DoCommit3PC总结TCC（Try-Confirm-Cancel）流程设计要点TCC总结 XA协议 在讲分布式事务之前，必然需要先了解XA协议。XA是一个协议，由Oracle Tuxedo系统提出的XA分布式事务协议。 XA协议定义了分布式事务参与方的两个角色： 事务协调者（TM=Transaction Manager） 资源管
浅析分布式事务2PC、3PC、TCC
flynetcn的专栏
04-14 2147
很浅显的介绍了一下2PC、3PC、TCC的概念，如有错误还望温柔指正，分布式事务一直都是面试中比较热点的问题，也是进阶高级工程师必备的知识点。
分布式事务(一)-2PC、3PC、TCC
路辉的博客
02-26 973
分布式事务一分布式事务理论分布式事务解决方案2PC-两阶段提交协议 分布式事务理论 CAP理论，即一致性、可用性、分区容错性，三者不可兼得，一般在后两者不可缺失的情况下，只能不追求强一致性，追求最终一致性 分布式事务解决方案 2PC两阶段提交协议 3PC三阶段提交协议 TCC 消息中间件 LCN 2PC-两阶段提交协议 如果有AB两个应用，2PC是通过一个协调者节点来保证这两个应用的一致 ...
2PC、3PC 和 TCC
11-03 321
对于单机下的本地事务，很显然我们有已被实践证明的成熟 ACID 模型来保证数据的严格一致性。但对于一个高访问量、高并发的分布式系统来说，如果我们期望实现一套严格满足 ACID 特性的分布式事务，很可能出现的情况就是在系统的可用性和严格一致性之间出现冲突——因为当我们要求分布式系统具有严格一致性时，很可能就要牺牲掉系统的可用性。但毋庸置疑的一点是，可用性又是一个所有用户不允许我们讨价还价的属性，比如...
2PC、3PC及TCC协议
Jay的博客
08-14 532
数据库事务的概念 在讲述分布式事务的概念之前，我们先来回顾下事务相关的一些概念。 事务的基本概念： 就是一个程序执行单元，里面的操作要么全部执行成功，要么全部执行失败，不允许只成功一半另外一半执行失败的事情发生。例如一段事务代码做了两次数据库更新操作，那么这两次数据库操作要么全部执行成功，要么全部回滚。 事务的基本特性： 我们知道事务有4个非常重要的特性，即我们常说的（ACID）。 Atomicity（原子性）:是说事务是一个不可分割的整体，所有操作要么全做，要么全不做；只要事务中有一个操作出错，回滚到事务
什么是2PC 3PC TCC?
qq_16047373的博客
07-07 223
2PC(两阶段提交) 阶段1 在阶段1中，协调者发起一个提议，分别问询各参与者发送事务预处理请求(可不可以执行任务) 阶段2 在阶段2中，协调者根据参与者的反馈，提交或中止事务，如果参与者全部同意则提交，只要有一个参与者不同意就中止。 缺点 同步阻塞问题。执行过程中，所有参与节点都是事务阻塞型的。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。 单点故障。由于协调者的重要...
分布式一致性（2pc/3pc/tcc/GTS）--极简总结
后起秀厚勃发
05-14 800
CAP： 一致性 可用性 分区容错性 最多只能满足2个， BASE： Basic Avialle / Sofe state/consistent 可用、0.5ms 变成1-2秒 软状态：中间状态，事后补齐数据 一致性：最终一致性 2PC 第一阶段：预提交，参与者写redo undo /更新数据，但是不提交事务 第二阶段：提交数据 3PC 第一阶段：准备阶段，做一些校验得的事情（超时终止） 第二阶段：预提交（超时自动提交） 第三阶段：提交（） 这...
2pc 与3pc
qq_23960265的博客
05-20 790
1.2pc优缺点：优点：原理简单，实现方便缺点：同步阻塞、单点问题、脑裂、太过保守同步阻塞：所有参与该事物操作得逻辑都处于阻塞状态单点问题：协调者有单点问题数据不一致：在协调则向所有参与者发送Commit请求后，发生故障，只有部分参与者收到Commit请求，没有收到得则不能提交，存在数据不一致情况。太过保守：没有设计较为完善得容错机制，任意一个节点得失败都会导致整个事物得失败。3.pc分为三个阶段...
分布式事务（2PC、3PC、TCC、LCN
03-15
### 分布式事务的概念 分布式事务是指在一个分布式系统中，为了保证跨多个节点的数据一致性而设计的一种机制。它涉及多个独立的服务或模块之间的协调工作，这些服务可能运行在不同的物理机器上或者不同的进程中。 #### 两阶段提交 (2PC) 两阶段提交是一种强一致性的协议，用于确保所有参与的节点都能成功完成它们的操作。其过程分为两个阶段： 1. **准备阶段**: 协调者询问参与者是否准备好提交事务。每个参与者会尝试执行所需的操作并锁定资源，但不会真正提交更改。如果一切正常，参与者回复“同意”，否则回复“取消”。 2. **提交阶段**: 如果所有的参与者都返回了“同意”的响应，那么协调者发送“提交”消息给所有参与者，此时参与者正式提交他们的操作并释放锁。如果有任何一个参与者不同意，则整个事务被回滚。这种方法虽然能保证数据的一致性，但在高并发环境下性能较差，并且容易造成单点故障[^4]。 ```java public class TwoPhaseCommit { public void prepare() throws Exception { /*...*/ } public void commit() throws Exception { /*...*/ } public void rollback() throws Exception { /*...*/ } } ``` #### 三阶段提交 (3PC) 作为对传统二阶段提交改进版本之一的是三阶段提交协议。该方法试图减少阻塞时间并通过引入超时机制来提高系统的可用性和可靠性。具体来说，它增加了一个额外的状态——预投票(pre-vote)，从而允许某些情况下即使部分成员未及时回应也能继续推进流程。 - 预备阶段：类似于2PC的第一步； - 提交请求阶段：当预备状态完成后，领导者发出实际提交指令前先确认是否有足够的票数支持此次交易； - 实际提交/终止阶段：依据前面收集的信息决定最终动作是提交还是撤销。 相比起标准版TPC, 这种做法理论上降低了死锁风险同时也增强了容错能力不过代价就是复杂度上升不少而且依旧难以完全摆脱网络分区带来的影响. #### TCC 补偿事务 TCC 是 Try Confirm Cancel 的缩写形式代表了一类轻量级解决方案适用于那些不需要严格ACID特性的应用场景下。在这种模型里面开发者自行定义三个主要的动作函数分别对应着试探性预留资源(Try), 正式占用资源(Confirm) 及清理之前所做的准备工作(Cancel)[^2]: - `Try` 方法负责检查必要的条件并且做初步预定; - `Confirm` 则是在确定无误之后才去落实真正的改变; - 而一旦出现问题则依靠 `Cancel` 来撤消先前的一切努力恢复原状; 值得注意的是这里并没有强制要求数据库本身具备完整的事务特性因此非常适合用来处理一些异构环境下的协同作业需求另外由于全部逻辑均由程序员手动编码实现故灵活性极高但是同样也意味着更高的维护难度和技术门槛. ```python class TccTransaction: def try_action(self): pass def confirm_action(self): pass def cancel_action(self): pass def execute_tcc(transaction): transaction.try_action() if success: transaction.confirm_action() else: transaction.cancel_action() ``` #### LCN 全局事务管理器 LCN(Lightweight Cloud Native)是由阿里巴巴开源出来专门针对云原生架构特点优化过的另一种新型分布式事务框架。它的核心理念在于利用中心化的控制器统一调度分散各地的小型局部单元共同构建出一套更大范围内的整体视图进而达成全局范围内的一致效果[^3]. 在这个体系结构当中每一个具体的业务环节都被封装成为单独的任务实例交给特定的工作线程池去异步执行与此同时主控端持续跟踪监控各个子任务的实际进展情况直到最后要么全体顺利完成要么果断采取补救措施防止错误扩散蔓延开来破坏其他健康组件的功能表现. --- ###
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值