分布式事务——9种解决方案的原理与分类_分布式事务问题有哪几种解决方案,各有何优缺点-CSDN博客

一、概要

1. 分布式事务的概念

官话： 分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于分布式系统的不同节点之上。简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成成功，要么全部失败。

白话： 本质上来说，分布式事务就是为了保证分散在各处的数据之间的一致性。

2. 分布式事务解决方案分类

分布式是否要考虑的第一个问题 —— 是否允许回滚：

若不允许回滚，则事务必须执行成功，不得执行失败，因此只能采用异步通知型策略，且需要设计重试与幂等
若允许回滚，则需要考虑第二个问题 —— 是否要加锁：
- 若要加锁，则事务为刚性事务（CP - 强一致性）
- 若不加锁，则事务为柔性事务（AP - 最终一致性），且只能采用同步补偿策略

分布式事务的分类
可以通过图表的方式更加清晰地划分各种不同的分布式事务解决方案和它们的设计思想：

分布式事务的分类图
接下来开始详细讲解这 9 种不同分布式事务解决方案的设计思想和优缺点。

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

1. 基础的 2PC（二阶段提交）

1.1 核心思想

对分布式事务最暴力的做法就是让所有参与者直接执行并提交本地事务，也就是一阶段提交（1PC）。
但是这样会导致事务失去回滚能力，各个参与者之间无法进行协同，极可能出现数据不一致的问题。
当然，也可以选择放弃事务的回滚能力，要求事务必须执行成功，此时即为异步通知型事务，也即某种意义上的 1PC 模式。

为了给予分布式事务中的各个参与者协调与回滚的能力，自然地提出二阶段提交的方案：

各个参与者先执行而不提交，若所有参与者都执行成功则提交，若有某个参与者执行失败则其他参与者随之回滚。

为了让各个参与者（资源管理器）之间可以做到同步，需要一个中心节点进行统一调度，也就是事务管理器。

1.2 简介

基础的 2PC

Prepare 阶段：
事务管理器给每个资源管理器发送 prepare 消息，资源管理器判断是否可以执行事务。
若可以执行，则开启本地事务，将事务写入本地的 redo log 和 undo log，但是不提交，然后返回成功；
若不可以执行，则返回失败。
Commit 阶段：
若事务管理器没有收到任何资源管理器的失败反馈，则给所有资源管理器发送 commit 消息；
若事务管理器收到了部分资源管理器的失败反馈，则给所有资源管理器发送 rollback 消息。
资源管理器根据收到的消息执行本地事务的 commit 或 rollback。

1.3 主要特点

1.3.1 优点

灵活性：相比于不允许回滚的分布式事务解决方案，能够允许事务的执行失败，因而灵活度更高。

1.3.2 缺点

并发性能： 很低，在提交前，数据库中的记录是被排它锁独占的，因此并发性能会很低。
稳定性： 如果事务管理器发送故障，RM 无法收到 TM 下达的提交命令，则未提交的数据就会长时间被锁。而此时，其他需要访问被锁数据的线程就会因无法访问而进入阻塞，随着阻塞线程越来越多，系统可能会崩溃。

核心的问题就在于对提交前数据的加锁，既导致了并发性能低的问题，也导致了线程阻塞的问题。
能不能不加锁？或能不能减少加锁时间？大部分允许回滚的改进方案都是基于这两个方面进行设计的。

2. 基础的 3PC（三阶段提交）

2.1 核心思想

3PC 模式试图通过减少加锁时间改进 2PC 模式。
为了解决 2PC 模式存在的问题，一个自然的想法就是引入超时机制，即资源管理器设等待超时时间，等待过久就自动提交或回滚，从而防止资源长期被锁导致的并发问题和线程阻塞问题。
然而，关键的问题在于在等待超时后 RM 该如何进行决策？是应该默认提交还是默认回滚？
如果不能做出可靠的决策，直接给 2PC 添加超时机制的简单做法极有可能导致数据不一致的问题。

为此，考虑在 2PC 模式的 prepare 阶段前加一个阶段，用于帮助超时后的默认操作进行决策。

2.2 简介

基础的 3PC

CanCommit 阶段（新增阶段）：
事务管理器询问每个资源管理器是否可以执行事务。
若可以执行，则资源管理器返回 Yes；若不可以执行，则资源管理器返回 No。
PreCommit 阶段（2PC 的 Prepare 阶段）：
若事务管理器收到的所有回复均为 Yes，则向所有资源管理器发送 PreCommit 消息；
若事务管理器收到的部分回复为 No，则向所有资源管理器发送 Abort 消息。
若资源管理器收到 PreCommit 消息，则执行事务但不提交；若资源管理器收到 Abort 消息，则中断事务。

若某 RM 等待超时，则选择中断本地事务。分如下两种情况讨论。

实际上 TM 发送了 PreCommit 消息，但是该 RM 已中断，其他 RM 也无法执行 DoCommit
阶段，也就无法提交本地事务，因此全局事务失败，不会发生数据不一致。

实际上 TM 发送了 Abort 消息，则该 RM 执行的中断是正确的操作，全局事务本应失败，保证了数据一致。