分布式事务的八种方案解析(1)

针对不同的分布式场景业界常见的解决方案有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会进行重试。

● 分支事务成功情况：

● image分支事务失败的情况：

imageTCC分为三个阶段

● 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的失败情况，做好幂等处理