07：分布式事务的四种解决方案

分布式事务的四种解决方案

一、两阶段提交（2PC）

• 两阶段提交（Two-phase Commit，2PC），通过引入协调者（Coordinator）来协调参与者的行为，并最终决定这些参与者是否要真正执行事务。运行过程准备阶段协调者询问参与者事务是否执行成功，参与者发回事务执行结果。
  

• 提交阶段如果事务在每个参与者上都执行成功，事务协调者发送通知让参与者提交事务；否则，协调者发送通知让参与者回滚事务。需要注意的是，在准备阶段，参与者执行了事务，但是还未提交。

• 只有在提交阶段接收到协调者发来的通知后，才进行提交或者回滚。
  

• 存在的问题

• 2.1 同步阻塞 所有事务参与者在等待其它参与者响应的时候都处于同步阻塞状态，无法进行其它操作。

• 2.2 单点问题 协调者在 2PC 中起到非常大的作用，发生故障将会造成很大影响。特别是在阶段二发生故障，所有参与者会一直等待状态，无法完成其它操作。

• 2.3 数据不一致 在阶段二，如果协调者只发送了部分 Commit 消息，此时网络发生异常，那么只有部分参与者接收到 Commit 消息，也就是说只有部分参与者提交了事务，使得系统数据不一致。

• 2.4 太过保守 任意一个节点失败就会导致整个事务失败，没有完善的容错机制。

二、补偿事务（TCC）

• 针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作。它分为三个阶段：
• Try 阶段主要是对业务系统做检测及资源预留Confirm 阶段主要是对业务系统做确认提交，Try阶段执行成功并开始执行 Confirm阶段时，默认 Confirm阶段是不会出错的。
• 即：只要Try成功，Confirm一定成功。
• Cancel 阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放。
• 优点： 跟2PC比起来，实现以及流程相对简单了一些，但数据的一致性比2PC也要差一些
• 缺点： 缺点还是比较明显的，在2,3步中都有可能失败。TCC属于应用层的一种补偿方式，所以需要程序员在实现的时候多写很多补偿的代码，在一些场景中，一些业务流程可能用TCC不太好定义及处理。

三、本地消息表（异步确保）

• 本地消息表是一种常用的分布式事务解决方案，其基本思想是将分布式事务拆分为多个本地事务，然后通过消息服务来协调这些本地事务。其实现原理如下：

1. 创建消息表：在数据库中创建一个消息表，用于存储待发送的消息。

2. 业务操作和消息表操作在同一本地事务中：当需要执行一个分布式事务时，首先在本地数据库中执行业务操作，然后在同一事务中向消息表中插入一条待发送的消息。这样可以保证业务操作和消息表操作的原子性。

3. 消息发送：有一个独立的消息发送服务，定期扫描消息表，将待发送的消息发送出去。

4. 消息确认：当消息接收方收到消息并处理成功后，会向消息发送方发送一个确认消息。

5. 消息删除：当消息发送方收到确认消息后，会删除消息表中对应的消息。

• 通过这种方式，即使在分布式环境中，也能保证事务的一致性。如果某个本地事务失败，那么对应的消息就不会被发送，从而保证了分布式事务的一致性。
  

• 优点： 一种非常经典的实现，避免了分布式事务，实现了最终一致性。

• 缺点： 消息表会耦合到业务系统中，如果没有封装好的解决方案，会有很多杂活需要处理。

四、MQ 事务消息

• 在分布式事务中，MQ（消息队列）事务消息的实现原理通常涉及两阶段提交协议（2PC）。以下是其基本步骤：

1. 准备阶段：生产者向 MQ 发送预备消息，此时消息并不会被消费者消费，而是处于待确认状态。

2. 执行本地事务：生产者收到 MQ 的预备消息确认后，开始执行本地事务（如数据库操作）。

3. 提交阶段：

• 如果本地事务成功，生产者会向 MQ 发送提交操作，MQ 收到提交操作后，会将消息状态改为可消费，消费者就可以消费这条消息了。

• 如果本地事务失败，生产者会向 MQ 发送回滚操作，MQ 收到回滚操作后，会删除这条预备消息。

• 这种方式保证了消息的可靠性传递和事务的一致性。即使在分布式环境中，也能保证事务的原子性和持久性。
  

• 优点： 实现了最终一致性，不需要依赖本地数据库事务。

• 缺点： 实现难度大，主流MQ不支持，RocketMQ事务消息部分代码也未开源。