分布式事务

最新推荐文章于 2024-11-08 22:04:16 发布

GrayGo

最新推荐文章于 2024-11-08 22:04:16 发布

阅读量142

点赞数

分类专栏：分布式理论文章标签：分布式

本文链接：https://blog.csdn.net/GrayGo/article/details/119942428

版权

1 篇文章 0 订阅

订阅专栏

本文深入探讨了分布式事务中的2PC（两阶段提交）协议，包括其工作流程、优缺点。接着介绍了为解决2PC问题而提出的3PC（三阶段提交）协议，以及其在2PC基础上的改进。此外，还提及了TCC（Try-Confirm-Cancel）补偿性事务处理方式，以提供更灵活的事务管理策略。

摘要由CSDN通过智能技术生成

两阶段提交 2pc

在这里插入图片描述

两阶段提交协议，简称2PC(2 Prepare Commit)，是比较常用的解决分布式事务问题的方式，要么所有参与进程都提交事务，要么都取消事务，即实现ACID中的原子性(A)的常用手段。

在这里插入图片描述
阶段一：

阶段二：

假如任何一个参与者向协调者反馈了No响应，或者在等待超时之后，协调者尚无法接收到所有参
与者的反馈响应，那么就会中断事务
在这里插入图片描述
阶段一：

阶段二：

发送回滚请求
协调者向所有参与者发出Rollback请求
事务回滚
参与者接收到 Rollback 请求后，会利用其在阶段一中记录的 Undo 信息来执行事务回滚操作，并在完成回滚之后释放在整个事务执行期间占用的资源。
反馈事务回滚结果
参与者在完成事务回滚之后，向协调者发送 Ack 信息。
中断事务
协调者接收到所有参与者反馈的 Ack 信息后，完成事务中断。

同步阻塞
在二阶段提交的执行过程中，所有参与该事务操作的逻辑都处于阻塞状态，即当参与者占有公共资源时，其他节点访问公共资源会处于阻塞状态。
单点问题
若协调器出现问题，那么整个二阶段提交流程将无法运转，若协调者是在阶段二中出现问题时，那么其他参与者将会一直处于锁定事务资源的状态中，而无法继续完成事务操作
数据不一致
在阶段二中，执行事务提交的时候，当协调者向所有的参与者发送Commit请求之后，发生了局部网络异常或者是协调者在尚未发送完Commit请求之前自身发生了崩溃，导致最终只有部分参与者收到了Commit请求，于是会出现数据不一致的现象。
太过保守
在进行事务提交询问的过程中，参与者出现故障而导致协调者始终无法获取到所有参与者的响应信息的话，此时协调者只能依靠自身的超时机制来判断是否需要中断事务，这样的策略过于保守，即没有完善的容错机制，任意一个结点的失败都会导致整个事务的失败。