🥛 分布式事务

1. 相关理论

1) CAP

• C
  • 一致性
  • 所有节点访问同一份最新的数据副本
• A
  • 可用性
  • 非故障的节点在合理的时间内返回合理的响应（不是错误或者超时的响应）
• P
  • 分区容忍性
  • 分布式系统出现网络分区的时候，仍然能够对外提供服务
• 应用：
  • Zookeeper 实现的是 CP
    • ZAB 的 ELECTION, DISCOVERY, SYNCHRONIZATION 状态不对外提供服务，只有 BROADCAST 状态对外提供服务
  • Nacos 实现的是 CP & AP

2) BASE

• BA
  • 基本可用
  • 在出现不可预知故障的时候，允许损失部分可用性
    • 响应时间上的损失 | 系统功能上的损失
• S
  • 软状态
  • 允许系统中的数据存在中间状态（CAP 理论中的数据不一致），并认为该中间状态的存在不会影响系统的整体可用性，
  • 即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时
• E
  • 最终一致性
  • 系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态

---

2. 分布式事务解决方案

1) 2PC

流程图

特点：

1. 数据库 层面
2. 尽量保证 强一致性
3. 同步阻塞
   • 事务参与者 收到 commit 命令之前，资源会一直阻塞，得不到释放
4. 只有一个 协调者，存在 单点故障 问题
5. 极端条件下存在 数据不一致 风险
   • 如果在执行阶段，参与者脑裂或者其他故障导致没有收到commit请求，部分提交事务，部分未提交，那么数据不一致的问题就产生了

2) 3PC

流程图

特点：

1. 数据库 层面
2. CanCommit 阶段不会锁住资源
3. 引入 超时机制，一定程度上优化了 2PC 的 单点故障 问题
4. 仍然存在 数据不一致 的情况
   • 在 PreCommit 阶段，某个参与者发生脑裂，无法收到协调者的 rollback 信息，
   • 这时其他参与者执行 rollback 事务回滚，而脑裂的参与者超时之后继续提交事务，
   • 于是导致 数据不一致

3) TCC

流程图

特点：

1. 业务 层面
2. 对 业务的侵入较大 & 与业务紧耦合
3. 为了解决 单点故障 问题，需要 Confirm & Cancel 阶段不断重试，
   • 在不断重试过程中，还需要保证业务操作的 幂等性
4. Seata 实现了 该策略

4) MQ

流程图

特点：

1. 保证 最终一致性
2. 消费者只有本地事务执行成功后，才会消费该消息；否则 MQ 会一直推送该消息，直到本地事务执行成功
3. 期间存在 重试 操作，因此也需要保证 业务的幂等性