探索分布式事务解决方案：八种方案解析

前面已经学习了分布式事务的基础理论CAP 理论和 BASE 理论，以理论为基础，针对不同的分布式场景业界常见的解决方案有2PC、TCC、可靠消息最终一致性、最大努力通知等方案,**以下 总结8 种常见的解决方案，取名 八奇技**。帮助大家在实际的分布式系统中更好地运用事务。。

1.2PC

二阶段提交协议（Two-phase commit protocol），简称 2PC。2PC是将整个事务流程分为两个阶段：

• 1.准备阶段（Prepare phase）
• 2.提交阶段（commitphase）

2是指两个阶段，P是指准备阶段，C是指提交阶段

在计算机中部分关系数据库如Oracle、MySQL支持两阶段提交协议，如下图：

• 准备阶段（Prepare phase）：事务管理器给每个参与者发送Prepare消息，每个数据库参与者在本地执行事务，并写本地的Undo/Redo日志，此时事务没有提交。（Undo日志是记录修改前的数据，用于数据库回滚，Redo日志是记录修改后的数据，用于提交事务后写入据文件）
• 提交阶段（commit phase）：如果事务管理器收到了参与者的执行失败或者超时消息时，直接给每个参与者发送回滚(Rollback)消息；否则，发送提交(Commit)消息；参与者根据事务管理器的指令执行提交或者回滚操作，并释放事务处理过程中使用的锁资源。

注意:必须在最后阶段释放锁资源

下图展示了2PC的两个阶段，分成功和失败两个情况说明：

• 成功情况：

图片

• 异常情况：

图片

2PC优缺点：

优点

• 简单直观：逻辑清晰，易于理解和实现。
• 原子性保证:能够保证跨多个分布式节点的事务的原子性。

缺点：

• 同步阻塞：因为一阶段需要锁定数据库资源，等待二阶段结束才释放，性能较差，在高并发场景下不适用
• 单点故障问题，如果协调者在第二阶段崩溃，参与者可能会无限期地等待指令，因为它们不知道应该提交还是回滚。这使得整个系统容易受到单点故障的影响
• 数据不一致问题，如果在第二阶段中协调者向某些参与者发送了提交指令，而其他参与者因为网络问题没有收到指令，那么这些没有收到指令的参与者可能会选择回滚，导致数据不一致

2.3PC

3PC，即Three-Phase Commit，是一种分布式事务协议，用于在分布式系统中确保多个参与者之间的事务操作的一致性和可靠性。它是在两阶段提交（2PC）协议的基础上发展而来，解决了2PC协议可能出现的悬挂事务问题。

3PC协议将提交操作分为三个阶段，分别是准备阶段、提交准备阶段和提交阶段，每个阶段都有对应的操作和协议。

准备阶段（CanCommit）：

• 协调者：向所有参与者发送CanCommit准备请求，询问它们是否可以提交事务。
• 参与者：执行本地事务，检查是否能够执行，如果可以执行则返回可以提交，否则返回不可以提交。

提交准备阶段（PreCommit）：

• 协调者: 根据参与者的反馈情况决定是否进行提交准备

• 如果所有参与者都返回“可以提交”，协调者向所有参与者发送提交请求，告知它们可以进行提交准备。
• 如果有任何参与者返回“不可以提交”或者超时未响应，则协调者向所有参与者发送中止请求，取消事务。

提交阶段（DoCommit/DoAbort）：

• 如果协调者 接收到所有参与者的确认提交消息，则向所有参与者发送最终的提交请求，提交事务。
• 如果协调者接收到任何参与者的中止请求，或者在提交准备阶段超时未收到所有参与者的响应，则向所有参与者发送中止请求，取消事务

3PC协议相对于2PC协议的改进在于增加了一个准备阶段，使得参与者在准备阶段就能够知道是否可以提交事务，从而避免了悬挂事务问题。然而，3PC协议仍然存在着协调者单点故障、消息丢失等问题，因此在实际应用中并不常见，一般更多地使用2PC、Saga等分布式事务解决方案

3.TCC

TCC是Try、Confirm、Cancel三个词语的缩写，TCC要求每个分支事务实现三个操作：预处理Try、确认Confirm、撤销Cancel。Try操作业务检查及资源预留，Confirm做业务确认操作，Cancel实现一个与Try相反的操作即回滚操作。TM首先发起所有的分支事务的try操作，任何一个分支事务的try操作执行失败，TM将会发起所有分支事务的Cancel操作，若try操作全部成功，TM将会发起所有分支事务的Confirm操作，其中Confirm/Cancel操作若执行失败，TM会进行重试。

• 分支事务成功情况：

图片

• 分支事务失败的情况：

图片

TCC分为三个阶段

• Try 阶段：是做业务检查(一致性)及资源预留(隔离)，此阶段仅是一个初步操作，它和后续的Confirm 一起才能真正构成一个完整的业务逻辑。
• Confirm 阶段：是做确认提交，Try阶段所有分支事务执行成功后开始执行 Confirm。通常情况下，采用TCC则认为 Confirm阶段是不会出错的。即：只要Try成功，Confirm一定成功。若Confirm阶段真的出错了，需引入重试机制或人工处理。。
• Cancel 阶段：是在业务执行错误需要回滚的状态下执行分支事务的业务取消，预留资源释放。通常情况下，采用TCC则认为Cancel阶段也是一定成功的。若Cancel阶段真的出错了，需引入重试机制或人工处理

TCC需要注意三种异常处理

空回滚

在没有调用 TCC 资源 Try 方法的情况下，调用了二阶段的 Cancel 方法，Cancel 方法需要识别出这是一个空回滚，然后直接返回成功。

出现原因：是当一个分支事务所在服务宕机或网络异常，分支事务调用记录为失败，这个时候其实是没有执行Try阶段，当故障恢复后，分布式事务进行回滚则会调用二阶段的Cancel方法，从而形成空回滚。

解决思路是

关键就是要识别出这个空回滚。思路很简单就是需要知道一阶段是否执行，如果执行了，那就是正常回滚；如果没执行，那就是空回滚。

幂等

TCC二阶段提交重试机制不会引发数据不一致，要求 TCC 的二阶段 Try、Confirm 和 Cancel 接口保证幂等，这样不会重复使用或者释放资源。如果幂等控制没有做好，很有可能导致数据不一致等严重问题。

解决思路 在上述“分支事务记录”中增加执行状态，每次执行前都查询该状态。

悬挂

悬挂就是对于一个分布式事务，其二阶段 Cancel 接口比 Try 接口先执行。

出现原因： 在 RPC 调用分支事务try时，先注册分支事务，再执行RPC调用，如果此时 RPC 调用的网络发生拥堵，通常 RPC 调用是有超时时间的，RPC 超时以后，TM就会通知RM回滚该分布式事务，可能回滚完成后，RPC 请求才到达参与者真正执行，而一个 Try 方法预留的业务资源，只有该分布式事务才能使用，该分布式事务第一阶段预留的业务资源就再也没有人能够处理了，对于这种情况，我们就称为悬挂，即业务资源预留后没法继续处理。

解决思路：如果二阶段执行完成，那一阶段就不能再继续执行。在执行一阶段事务时判断在该全局事务下，“分支事务记录”表中是否已经有二阶段事务记录，如果有则不执行Try。

TCC优缺点：

TCC的优点：

• 一阶段完成直接提交事务，释放数据库资源，性能好
• 无需使用全局锁，性能最强
• 不依赖数据库事务，而是依赖补偿操作，可以用于非事务型数据库

TCC的缺点

• 有代码侵入，需要人为编写try、Confirm和Cancel接口，太麻烦
• 软状态，事务是最终一致
• 需要考虑Confirm和Cancel的失败情况，做好幂等处理

4. 分布式补偿事务（Saga）

Saga是一种长事务的解决方案，它将一个大的分布式事务拆分成多个较小的本地事务，并通过异步消息传递来串联这些本地事务。每个本地事务执行成功后，会发送消息触发下一个事务的执行。如果某个本地事务失败，Saga会执行一系列补偿操作，保持数据的一致性。

分布式补偿事务（Saga） 优缺点

优点

• 灵活性： 允许每个小事务独立管理，提高了系统的灵活性。
• 减少资源锁定： 不需要持续占用资源，提高了系统的并发能力。
• 容错性： 通过定义补偿操作来处理失败，增强了系统的容错能力。
• 适用于微服务架构： 可以跨服务边界管理事务，每个服务都可以独立处理自己的事务和补偿逻辑。

缺点

• 复杂性： 实现Saga需要定义每个小事务的补偿操作，增加了系统的复杂性。
• 数据一致性： 不能提供即时一致性保证，只能保证最终一致性。
• 补偿操作的难度： 在某些情况下，补偿操作可能很难实现，特别是当事务有副作用时。
• 测试和调试： 涉及多个服务和补偿逻辑，测试和调试可能会更加困难。

在选择使用Saga模式时，需要仔细考虑业务场景是否适合最终一致性，以及是否能够有效地实现和管理补偿逻辑。对于需要高度一致性保证的场景，可能需要考虑其他事务管理机制。Saga模式在适当的情况下可以为分布式系统带来灵活性和容错性，但需要慎重考虑其复杂性和实现难度。

5. 可靠消息最终一致性

可靠消息最终一致性方案：是指当事务发起方执行完成本地事务后并发出一条消息，事务参与方(消息消费者)一定能够接收消息并处理事务成功，此方案强调的是只要消息发给事务参与方最终事务要达到一致。

此方案是利用消息中间件完成，如下图：

图片

事务发起方（消息生产方）将消息发给消息中间件，事务参与方从消息中间件接收消息，事务发起方和消息中间件之间，事务参与方（消息消费方）和消息中间件之间都是通过网络通信，由于网络通信的不确定性会导致分布式事务问题。

可靠消息最终一致性方案要解决以下几个问题

1. 本地事务与消息发送的原子性问题

本地事务与消息发送的原子性问题即：事务发起方在本地事务执行成功后消息必须发出去，否则就丢弃消息。即实现本地事务和消息发送的原子性，要么都成功，要么都失败。本地事务与消息发送的原子性问题是实现可靠消息最终一致性方案的关键问题。 先来尝试下这种操作，先发送消息，再操作数据库：

begin transaction；
//1.发送MQ
//2.数据库操作
commit transation;