架构视角下的分布式事务（一）：核心理论与强一致性方案

微服务架构下的分布式事务解决方案

第一篇内容：

1. 什么是分布式事务（定义、产生背景、核心难点）
2. 什么时候使用（跨库、跨服务场景、电商案例）
3. 理论基石（CAP 权衡、CP vs AP）
4. 强一致性方案（2PC 详解与缺陷、3PC 的改进与局限）

第二篇内容：

1. TCC 补偿型事务（Try-Confirm-Cancel 详解、三大异常处理）
2. 可靠消息最终一致性（基于 MQ + 本地消息表方案）
3. Saga 长事务模式（编排式 vs 协同式、ACD 模型）
4. 全文总结与选型建议
   架构视角下的分布式事务（二）：柔性事务与最终一致性方案

什么是分布式事务

用最通俗的话来说，分布式事务就是由多个“本地事务”组合而成的一个宏观事务。

• 本质：它是一种机制，用于保证跨越多个节点（不同的数据库、不同的服务器、不同的微服务）的一系列操作，要么全部成功，要么全部失败（回滚），从而保持数据的一致性。
• 核心难点：本地事务（Local Transaction）只能保证同一个数据库内的操作是原子的（ACID），但当业务逻辑分散在不同的数据库或服务中时，中间经历了复杂的网络环境，本地事务就无能为力了。

什么时候使用分布式事务?

核心场景主要有两个：跨数据库和跨服务。

只要业务操作满足以下条件，就需要考虑分布式事务：

1. 涉及多个数据源：业务逻辑需要同时修改 Database A 和 Database B 中的数据。
2. 涉及多个微服务：业务流程需要调用 Service A 和 Service B，而这两个服务分别操作不同的数据库。
3. 需要强一致性或最终一致性：不能容忍数据出现“一边成功，另一边失败”的中间状态。

具体的经典案例：

场景：电商下单

• 动作 1：订单服务需要在订单表中创建一条订单记录。
• 动作 2：库存服务需要在库存表中扣减对应的商品库存。

如果不使用分布式事务会发生什么？

• 如果“创建订单”成功了，但是网络抖动导致“扣减库存”失败了。
• 结果：用户有了订单，但库存没扣，导致超卖（数据不一致）。
• 或者反过来：库存扣了，订单没创建成功，导致少卖。

引入分布式事务后：
系统会确保“创建订单”和“扣减库存”这两个动作绑定在一起。如果其中任何一步失败，整个操作都会回滚，保证数据的准确性。

分布式事务的两种主要流派

理论基石：CAP 理论与取舍

在分布式系统中，P（Partition Tolerance，分区容错性）是必须要保证的客观基础，因为网络通信必然存在不稳定性。因此，我们只能在C（Consistency，一致性）和A（Availability，可用性）之间做二选一的博弈：

• CP 策略（重一致性）：牺牲可用性，保证数据强一致。在数据未达成一致前，系统会阻塞或返回错误，直到数据同步完成。
• AP 策略（重可用性）：牺牲强一致性，保证高可用。允许系统暂时返回旧版本数据或中间状态，但保证最终一致。

第一流派：强一致性方案 (CP 模型)

这一流派对应 CAP 理论中的CP侧重。它致力于在分布式环境下延伸传统的ACID（原子性、一致性、隔离性、持久性）语义。

• 核心逻辑：
  所有节点在进行事务操作时，必须保持高度同步。在事务提交的过程中，数据资源通常会被锁定，直到所有节点都确认成功，事务才算结束。

• 技术特点：

  • 同步阻塞（Synchronous Blocking）：参与事务的各个服务在等待协调者指令时，处于阻塞状态，无法处理其他请求。
  • 刚性事务：不允许出现“部分成功”的中间状态，对业务层透明（业务代码感知不到事务的复杂性）。

• 优缺点分析：

  • 优点：开发成本相对较低（模型简单），数据一致性极高，无“脏读”风险。
  • 缺点：性能瓶颈明显。由于长周期的资源锁定（Locking）和网络通信开销，系统的并发吞吐量（Throughput）会显著下降，且容易出现死锁或单点故障问题。

• 代表技术：

  1. 2PC (Two-Phase Commit) / XA 协议：经典的准备（Prepare）和提交（Commit）两阶段模式。
  2. Seata (AT 模式)：阿里巴巴开源的分布式事务框架。它在 2PC 基础上进行了优化（使用 Undo Log 实现回滚），虽然减少了数据库锁的持有时间，但在全局层面依然呈现出强一致性的特征。

第二流派：最终一致性方案 (AP 模型 + BASE 理论)

这一流派对应 CAP 理论中的AP侧重，并遵循BASE 理论（Basically Available 基本可用、Soft state 软状态、Eventually consistent 最终一致性）。

• 核心逻辑：
  承认系统在短时间内可以存在数据不一致的中间状态（软状态），通过异步消息、补偿机制或重试机制，确保在一定时间窗口后，所有数据最终达到一致。

• 技术特点：

  • 异步非阻塞（Asynchronous Non-blocking）：各个服务执行完本地事务后立即返回，不等待其他服务的结果，极大地释放了系统资源。
  • 柔性事务：业务层需要感知事务状态，通常需要编写“正向操作”和“反向补偿（回滚）”的业务代码。

• 优缺点分析：

  • 优点：高并发、高可用。系统扩展性强，能够应对流量削峰填谷的场景，适合互联网核心业务（如下单、支付）。
  • 缺点：实现复杂度高。开发人员需要处理幂等性（Idempotency）、空回滚、悬挂等复杂问题，且用户体验上可能会看到“处理中”的状态。

• 代表技术：

  1. TCC (Try-Confirm-Cancel)：业务层面的两阶段提交。通过预留资源（Try）、确认资源（Confirm）和撤销资源（Cancel）三个接口来实现，侵入性强但控制粒度最细。
  2. 可靠消息最终一致性 (MQ)：利用消息队列（如 RocketMQ 的事务消息）解耦。上游投递消息，下游消费消息，通过 ACK 机制和重试保证最终成功。
  3. Saga 模式：将长事务拆分为多个本地短事务链。如果某个环节失败，则按照相反顺序执行一系列补偿操作（Compensating Transactions）来回滚。

2PC - 两阶段提交

2PC 协议定义

2PC 是一种原子性提交协议（Atomic Commitment Protocol），旨在解决分布式系统中的数据一致性问题。它通过引入一个协调者（Coordinator）来管理所有参与者（Participant/Resource Manager）的提交行为，确保分布式事务要么全部提交（Commit），要么全部回滚（Rollback），从而满足 ACID 中的原子性（Atomicity）。

2PC 执行流程

该协议将事务提交过程显式地划分为两个阶段：准备阶段 (Prepare Phase)和提交阶段 (Commit Phase)。

1. 准备阶段

• 询问：协调者向所有参与者发送Prepare请求，询问是否可以执行事务提交操作。
• 执行与日志：参与者执行本地事务操作，并将 Undo Log（用于回滚）和 Redo Log（用于恢复）写入持久化存储。
• 资源锁定：此时，参与者必须锁定相关资源（如数据库行锁），但不提交事务。
• 响应：如果执行成功，参与者反馈Yes（Ready）；如果执行失败，反馈No（Abort）。

2. 提交阶段

协调者根据阶段一的投票结果进行决策：

• Commit 路径：若所有参与者均反馈Yes，协调者向所有参与者发送Commit请求。参与者正式提交事务，释放持有的锁资源，并向协调者发送 Ack。
• Rollback 路径：若任意参与者反馈No或协调者等待超时，协调者向所有参与者发送Rollback请求。参与者利用 Undo Log 进行回滚，释放锁资源，并发送 Ack。

2PC 核心缺陷深度解析

2PC 是一种阻塞式协议 (Blocking Protocol)，这一特性导致了其在工程实践中的三大核心问题：

1. 同步阻塞

这是 2PC 在性能上的最大瓶颈。

• 机制原理：在从“准备阶段”回复Yes开始，直到“提交阶段”完成之前，参与者的所有相关资源（数据库连接、行锁、表锁）均处于锁定状态。
• 后果：
  • 资源竞争（Resource Contention）：在此期间，任何其他并发事务试图访问该资源都会被阻塞（Blocked）。
  • 性能衰减：事务持锁时间由网络最慢的节点决定（木桶效应）。在高并发场景下，这种长时间的锁持有会导致严重的吞吐量下降。

2. 单点故障

协调者的可用性直接决定了系统的存活能力。

• 机制原理：协调者负责维护全局事务的状态并驱动流程。
• 故障场景：若协调者在**阶段二（发送 Commit/Rollback 指令前）**宕机。
• 后果：
  • 资源死锁：所有参与者已处于PREPARED状态，锁定了资源。由于没有收到协调者的最终指令，参与者无法判断应该提交还是回滚（它不知道其他节点的投票结果）。
  • 无法自愈：参与者将一直持有锁并处于阻塞状态，直到协调者恢复或人工介入。这被称为2PC 的阻塞问题。

3. 数据不一致

这是 2PC 在一致性保证上的逻辑漏洞。

• 机制原理：阶段二的广播并非原子操作。
• 故障场景：在阶段二，协调者决定 Commit，并向参与者 A 发送了Commit请求，A 执行并提交。但在向参与者 B 发送请求前，协调者发生网络分区或宕机。
• 后果：
  • 状态分裂：参与者 A 的数据已提交（Durable），而参与者 B 仍处于锁定等待状态（最终可能因超时而回滚）。
  • 原子性破坏：整个分布式系统出现了“部分提交、部分未提交”的中间状态，违背了 ACID 中的 Atomicity。

3PC - 三阶段提交

3PC

3PC是针对 2PC 的**阻塞问题（Blocking Problem）**提出的改进版本。
其核心改进在于：

1. 将 2PC 的“准备阶段”一分为二，形成了CanCommit和PreCommit两个阶段。
2. 引入超时机制（Timeout Mechanism）：不仅协调者拥有超时机制，参与者也引入了超时机制，从而打破了参与者只能“傻等”的僵局。

3PC 执行流程

3PC 将事务流程划分为：CanCommit（询问阶段）、PreCommit（预提交阶段）、DoCommit（提交阶段）。

详细阶段解析

1. 阶段一：CanCommit (询问/质询)

   • 动作：协调者询问参与者：“你现在自身状态正常吗？能接活吗？”
   • 特点：这是一个轻量级的检查。参与者不锁定资源，只检查网络、数据库健康状况等。
   • 目的：快速失败（Fail-fast）。如果此时有节点挂了，直接中止，避免进入后续昂贵的锁资源阶段。

2. 阶段二：PreCommit (预提交)

   • 动作：如果阶段一全员通过，协调者发送PreCommit。
   • 逻辑：参与者执行事务操作，写入 Undo/Redo Log，锁定资源，但不提交。
   • 关键点：这相当于 2PC 的第一阶段。如果参与者在等待此指令时超时，会执行中断（Abort）。

3. 阶段三：DoCommit (提交)

   • 动作：如果阶段二全员成功，协调者发送DoCommit，参与者正式提交并释放锁。
   • 关键机制（自动提交）：如果参与者在阶段二回复了 Ack，进入阶段三，但超时未收到协调者的DoCommit或Abort指令，参与者会自动执行Commit（因为 3PC 假设如果到了这一步，其他节点大概率也是成功的）。

3PC 的改进与核心缺陷

1. 优势：降低阻塞

3PC 最大的贡献在于解决了 2PC 的单点故障导致的无限阻塞问题。

• 机制：参与者引入了超时策略。
• 场景：
  • 若参与者在PreCommit阶段等待超时 ->自动中止 (Abort)。
  • 若参与者在DoCommit阶段等待超时 ->自动提交 (Commit)。
• 结果：无论协调者何时宕机，参与者都能根据当前状态和超时策略，自动做出决策并释放锁资源，不会像 2PC 那样永久锁死。

2. 问题：数据不一致 - 网络分区场景

这是 3PC 依然未能解决，甚至在特定场景下加剧的问题。

• 场景复现（脑裂）：
  1. 进入阶段三，协调者发现某个节点反馈失败，或者协调者自己觉得需要回滚，于是发出Abort指令。
  2. 此时发生网络分区。
  3. 参与者 A收到了Abort指令 -> 执行回滚。
  4. 参与者 B没有收到任何指令（因为网络断了），等待超时。
• 致命逻辑：根据 3PC 的协议设计，参与者 B 在阶段三超时后，会默认执行Commit（因为它认为既然能进阶段三，说明阶段二大家都成功了）。
• 结果：A 回滚了，B 提交了。数据严重不一致，且无法自动修复。

3. 问题：性能与复杂度开销

• 通信开销：相比 2PC 的两个 RTT（Round Trip Time，往返时延），3PC 需要3个 RTT才能完成一个事务。网络交互次数增加 50%。
• 实现复杂：状态机逻辑更加复杂，维护成本高。

总结

3PC 在理论上是一个优化的协议（Non-blocking atomic commitment），但在工程实践中（如数据库内核、微服务架构）极少被实际应用。

• 它虽然缓解了阻塞，但没有解决一致性问题。
• 它带来的性能损耗（3次握手）通常被认为是不划算的。
• 在工业界，大家宁愿使用2PC 的优化版（如 Seata AT）或者Paxos/Raft这种共识算法来解决一致性问题，而不是使用 3PC。