常见的分布式事务解决方案

最新推荐文章于 2025-02-26 02:36:36 发布

肚子饿没人理

最新推荐文章于 2025-02-26 02:36:36 发布

阅读量1.7k

点赞数

分类专栏：分布式系统文章标签：分布式事务 2pc 3pc tcc mq

本文链接：https://blog.youkuaiyun.com/u010530712/article/details/86233426

版权

分布式系统专栏收录该内容

1 篇文章

订阅专栏

之前梳理了什么是事务;https://blog.youkuaiyun.com/u010530712/article/details/84949864

现在来梳理下，分布式事务的解决方案

首先对于分布式事务，一般来说要基于CAP（Consistency ：一致性，Availability ：可用性，Partition Tolerance：分区容错性）中的两个，要么CP(一致性 + 分区容忍性)，要么AP （可用性 + 分区容忍性），理论上是不可能选择CA（一致性+可用性）。

然而，CAP里的Consistency 是强一致性（忽略延迟），但是在实际的应用中，几乎没有系统能完全做到CP（因为总会有那么几毫秒的数据复制延迟在），因此我们追求的是“最终一致性”，即系统中的数据允许经过一定的时间后，最终达到一致的状态，这里的一定时间根据不同的业务需要，时间长短也不同。对于支付类的业务，用户关注，要求秒级别甚至毫秒级别达到一致性，而对于一些发帖子之类的论坛业务，数据复制延迟个10分钟，对于看的用户来说是无感知的。

说完了主要的一致性问题。下面正式介绍几种分布式事务解决方案

2PC（two-phase-commit，二阶段提交）方案

该方案将事务的提交扶持分为两个阶段：准备阶段和提交阶段，事务的发起方叫“协调者”，事务的执行方叫“参与者”

阶段 1：准备阶段

准备阶段有如下三个步骤：

协调者向所有参与者发送事务内容，询问是否可以提交事务，并等待所有参与者答复。
各参与者执行事务操作，将 undo 和 redo 信息记入事务日志中（但不提交事务）。
如参与者执行成功，给协调者反馈 yes，即可以提交；如执行失败，给协调者反馈 no，即不可提交。

阶段 2：提交阶段

如果协调者收到了参与者的失败消息或者超时，直接给每个参与者发送回滚(rollback)消息；否则，发送提交(commit)消息。

参与者根据协调者的指令执行提交或者回滚操作，注意！是最后释放所有事务处理过程中使用的锁资源（也就是从执行事务开始到协调者给予commit/rollback指令期间，一直是阻塞状态）。

2PC总结

性能问题：所有参与者在事务提交阶段处于同步阻塞状态，占用系统资源，容易导致性能瓶颈。
可靠性问题：如果协调者存在单点故障问题，如果协调者出现故障，参与者将一直处于锁定状态。
数据一致性问题：在阶段 2 中，如果发生局部网络问题，一部分事务参与者收到了提交消息，另一部分事务参与者没收到提交消息，那么就导致了节点之间数据的不一致。

3PC(three-phase-commit，三阶段提交)方案

三阶段提交相较二阶段提交，引入了超时机制（无论协调者还是参与者，在向对方发送请求后，若长时间未收到回应则做出相应处理）

三阶段将之前二阶段的准备阶段拆成2个阶段（cancommit：确认是否能执行，precommit：执行事务不提交）

阶段 1：canCommit

协调者向所有参与者发出包含事务内容的 canCommit 请求，询问是否可以提交事务，并等待所有参与者答复。
参与者收到 canCommit 请求后，如果认为可以执行事务操作，则反馈 yes 并进入预备状态，否则反馈 no。

阶段 2：preCommit

协调者根据阶段 1 canCommit 参与者的反应情况来决定是否可以进行基于事务的 preCommit 操作，如下表

情况 1

阶段 1 所有参与者均反馈 yes，参与者预执行事务：

协调者向所有参与者发出 preCommit 请求，进入准备阶段。
参与者收到 preCommit 请求后，执行事务操作，将 undo 和 redo 信息记入事务日志中（但不提交事务）。
各参与者向协调者反馈 ack 响应或 no 响应，并等待最终指令。

情况 2

阶段 1 任何一个参与者反馈 no，或者等待超时后协调者尚无法收到所有参与者的反馈，即中断事务，如上图：

协调者向所有参与者发出 abort 请求。
无论收到协调者发出的 abort 请求，或者在等待协调者请求过程中出现超时，参与者均会中断事务。

阶段 3：do Commit

注意：进入阶段 3 后，无论协调者出现问题，或者协调者与参与者网络出现问题，都会导致参与者无法接收到协调者发出的 do Commit 请求或 abort 请求。此时，参与者都会在等待超时之后，继续执行事务提交。

情况 1：阶段 2 所有参与者均反馈 ack 响应，执行真正的事务提交	如果协调者处于工作状态，则向所有参与者发出 do Commit 请求。参与者收到 do Commit 请求后，会正式执行事务提交，并释放整个事务期间占用的资源。各参与者向协调者反馈 ack 完成的消息。协调者收到所有参与者反馈的 ack 消息后，即完成事务提交。
情况 2：阶段 2 任何一个参与者反馈 no，或者等待超时后协调者尚无法收到所有参与者的反馈，即中断事务	如果协调者处于工作状态，向所有参与者发出 abort 请求。参与者使用阶段 1 中的 undo 信息执行回滚操作，并释放整个事务期间占用的资源。各参与者向协调者反馈 ack 完成的消息。协调者收到所有参与者反馈的 ack 消息后，即完成事务中断。