关于 分布式事务 你知道多少

关于 分布式事务 你知道多少

1、概述

​  分布式事务 是指 事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的 分布式系统 的不同节点之上。

​  简单来说，分布式事务 就是 在分布式系统中多个本地事务组合而成的事务。从本质上讲，分布式事务就是为了保证不同数据库的数据一致性。

---

补充：

​  分布式事务问题的解决方案：

• 2PC
• TCC
• 本地消息表
• MQ 事务
• Saga 事务

---

2、2PC

​  2PC（Two Phase Commitment Protocol，二阶段提交协议）用于解决 分布式数据强一致性 问题，协议分为两个阶段处理，阶段一：提交事务请求，阶段二：执行事务提交，如果阶段一超时或者出现异常，阶段二就中断事务。

​  注：2PC 引入一个事务协调者来管理各参与者（本地资源）的提交和回滚。

阶段一（准备阶段）：提交事务请求

1. 事务询问：协调者 向 所有参与者 发送事务内容，询问是否可以执行提交操作，并开始等待各参与者进行响应；
2. 执行事务：各参与者 执行事务操作（未提交），并将 undo 和 redo 操作 记入本机事务日志；
3. 响应：各参与者 响应 协调者的事务询问，成功执行返回 yes，失败返回 no 。

阶段二（所有参与者返回 yes）：执行事务提交

1. 发送提交请求：协调者 向 所有参与者 发送 commit 请求；
2. 事务提交：各参与者 接收到 commit 请求之后，正式执行事务提交操作，并在完成之后释放资源；
3. 响应：各参与者 在完成各自的事务提交之后，向 协调者 发送 ack 消息确认；
4. 完成事务：协调者 收到 所有参与者的 ack 确认之后，事务完成。

阶段二（某一参与者返回 no）：中断事务

1. 发送回滚请求：协调者 向 所有参与者 发送 rollback 请求；
2. 执行回滚：各参与者 接收到 rollback 请求后，使用本机的 undo 日志 执行 rollback 操作，并在完成之后释放资源；
3. 响应：各参与者 在完成回滚操作之后，向 协调者 发送 Ack 消息确认；
4. 中断事务：协调 收到 所有参与者的 ack 确认之后，事务中断。

---

补充：2PC 的优缺点

优点：

• 实现原理简单。

缺点：

• 单点问题：协调者一旦在第一阶段完成之后发生宕机，所有参与者将一直处于阻塞状态（无法释放事务资源、无法完成事务操作），将导致数据库无法使用。
• 同步阻塞问题：在准备就绪之后，所有参与者都处于阻塞状态，直到提交完成。
• 数据不一致问题：在执行事务提交的过程中，如果协调者向所有参与者发送 commit 请求后，发生局域网络异常（或者协调者在尚未发送完 commit 请求 就发生宕机）导致 只有部分参与者 收到、执行请求，最终将导致在整个系统中参与者出现数据不一致的情况。

---

扩展：3PC

​  3PC（Three-Phase Commit）是 2PC 的改进版，它将原有的两阶段过程重新划分为 准备阶段（CanCommit）、预提交阶段（PreCommit）、提交阶段（DoCommit） 三个阶段。

​  3PC 与 2PC 的区别在于：它在 协调者 和 参与者中都引入 超时机制，并把 2PC 中的 第一阶段 拆分成两个阶段：询问（CanCommit 阶段）、锁资源（PreCommit 阶段）。

---

3、TCC

​  TCC（Try-Confirm-Cancel）是业务层面的分布式事务，通过对业务逻辑的分解来实现分布式事务，分为Try、Confirm、Cancel 三个阶段。

• Try 阶段：尝试执行，完成所有业务检查，预留必须业务资源；

• Confirm 阶段：对业务系统做确认提交，确认执行业务操作，不做其它业务检查，只使用 Try 阶段 预留的业务资源；

• Cancel 阶段：取消业务执行，释放 Try 阶段 预留的业务资源。

---

补充：

• Confirm 或 Cancel 阶段 两者是互斥的，只能进入其中一个，并且都满足幂等性，允许失败重试。
• TCC 中会添加事务日志，如果 Confirm（或 Cancel） 阶段 出错 会进行重试。

---

---

补充：TCC 的优缺点

优点：

• 适用范围大
• 强隔离性、严格一致性
• 跨数据库、跨业务系统

缺点：

• 对业务的侵入较大、和业务紧耦合
• 对于业务的每个操作都需要定义三个动作分别对应 Try-Confirm-Cancel，开发量大、代码维护难度高

---

4、本地信息表

​  本地信息表 的核心是 将需要分布式处理的任务 通过 消息日志 的方式来异步执行，消息日志 可以存储在 本地文本、数据库（常用）、消息队列，再通过业务规则自动（或人工）发起重试。

​  本地消息表 实现的是 最终一致性，容忍了 数据暂时不一致 的情况。

---

补充：

• 消息生产者 本地 要保存一张 消息表，记录消息的相关信息；
• 业务数据表 和 消息表 要保证在同一个数据库、同一个本地事务；
• 消息消费者 消费完消息后 通知 消息生产者 更新消息状态；
• 消息生产者 定时扫描 本地消息表，把 未处理的消息（或处理失败的消息）重发到 MQ 。

---

5、MQ 事务

​  以 RocketMQ 代表的 MQ 自身就实现了 分布式事务，MQ 事务从本质上看，是对本地消息表的一个封装（将本地消息表移动到了 MQ 内部）。

步骤：

1. 消息发送者 先给 broker 发送事务消息（即半消息，指该消息对消费者不可见）。
2. 如果 broker 响应 发送成功，就执行本地事务，如果执行成功，就向 broker 发送 commit（含事务内容）；否则，向 broker 发送 rollback 。
3. 如果 broker 接收到 commit，就将该消息发送给 消息订阅方。
4. 消息订阅方 接收到消息后，就根据消息内容执行事务（即消费该消息）。

注：RocketMQ 的发送方 会提供一个 回查事务状态接口，如果一段时间内 broker 都没有接收到 半消息，就会通过 反查接口 查询发送方事务是否执行成功（成功 对应 commit ，失败 对应 rollback）。

6、Saga 事务

​  Saga 事务 将 一个分布式事务 拆分成 多个本地事务，每个本地事务都有相应的 执行模块 和 补偿模块（类似于 TCC 中的 Confirm 和 Cancel），当 Saga 事务中任意一个本地事务出错时，可以通过调用相关的 补偿方法恢复之前的事务，达到事务最终一致性。

组成：

• LLT（Long Live Transaction）：由一个个本地事务组成的事务链。
• 本地事务：使用 Tn 表示。
• 补偿：使用 Cn 表示。

执行顺序：

• T1，T2，T3，…，Tn 。
• T1，T2，…，Tj，Cj，…，C2，C1（0 < j < n）。

恢复策略：

• 向后恢复（Backward Recovery）：撤销之前所有成功的子事务。
• 向前恢复（Forward Recovery）：重试失败的事务。

注：Saga 事务 不能保证隔离性（因为没有锁住资源），其它事务依然可以覆盖或影响当前事务。