分布式系统学习10：分布式事务

分布式系统学习10：分布式事务

分布式事务是分布式系统中保证数据一致性的关键机制。本文将深入探讨分布式事务的背景、理论基础、实现方案及其优缺点，帮助读者全面理解这一重要概念。

1. 知识体系

1. 为什么要用分布式事务

在单体架构中，业务操作（如下单、创建订单、扣减库存）可以在一个数据库事务中完成。然而，随着业务增长，系统演进为分布式系统，原有的单体架构被拆分为多个微服务。在这种情况下，需要保证跨多个服务的操作能够原子性地完成，以确保数据一致性，这就需要使用分布式事务。

2. 理论基础

分布式事务的理论基础可以分为两类：

• CP模式（刚性事务）：遵循ACID原则，强调强一致性。
• AP+BASE模式（柔性事务）：遵循BASE原则，允许一定时间内的数据不一致性，但要求最终达到一致性。

BASE理论

• 基本可用（Basically Available）：系统在出现未知故障时仍能提供服务。
• 软状态（Soft State）：允许系统存在中间状态，即不同副本的数据可以暂时不一致。
• 最终一致性（Eventually Consistent）：在一定时间后，所有副本的数据将保持一致。

3. 刚性事务（CP模式）

刚性事务基于XA协议，通过事务管理器（Transaction Manager）和本地资源管理器（Resource Manager）实现分布式事务的协调。常见的实现方式包括2PC（两阶段提交）和3PC（三阶段提交）。

3.1 两阶段提交（2PC）

2PC通过协调者（coordinator）和参与者（participant）来统一掌控事务操作。过程分为两个阶段：

• 准备阶段：协调者向所有参与者发送REQUEST-TO-PREPARE消息，参与者回复PREPARE或NO。
• 提交阶段：如果所有参与者都回复PREPARE，协调者发送COMMIT消息；否则发送ABORT消息。

2PC的缺点

• 网络抖动可能导致数据不一致。
• 超时会导致同步阻塞。
• 协调者单点故障风险。

3.2 三阶段提交（3PC）

3PC在2PC的基础上增加了准备阶段，并引入超时机制。过程分为三个阶段：

• CanCommit：检查是否可以执行事务提交。
• PreCommit：检查是否可以进行事务预提交。
• DoCommit：正式提交事务。

尽管3PC对2PC进行了优化，但两者在实际应用中都存在局限性，因此很少使用。

4. 柔性事务（AP + BASE 最终一致性）

柔性事务允许有中间态，强调最终一致性。常见的实现方式包括TCC、Saga、本地消息表、MQ事务方案和最大努力通知。

4.1 TCC 补偿事务

TCC（Try Confirm Cancel）是一种应用层面的补偿事务，包含三个操作步骤：

• Try阶段：完成业务检查，预留必须的业务资源。
• Confirm阶段：执行业务逻辑，需要满足幂等性。
• Cancel阶段：取消操作，释放预留资源，需要满足幂等性。

4.2 Saga事务

Saga事务通过一系列本地事务实现分布式事务，每个本地事务更新数据库后会触发下一个本地事务。Saga有两种实现方式：

• 基于事件的方式：没有协调中心，各服务按预设顺序执行。
• 基于命令的方式：由协调中心统一调度。

4.3 本地消息表

本地消息表方案将分布式事务拆分为本地事务处理，通过轮询消息表和MQ实现异步解耦。优点是方案轻量，但与业务强耦合。

4.4 MQ消息事务

MQ事务是对本地消息表的优化，将消息存储在MQ内部，通过重试机制保证最终一致性。缺点是每次消息发送需要两次网络请求。

4.5 最大努力通知

最大努力通知是对MQ事务的进一步优化，通过查询接口实现事务结果的主动获取。适用于业务通知类场景。

5. Seata框架

Seata是一个开源的分布式事务解决方案，支持AT、TCC、SAGA、XA等多种事务模式。其核心组件包括：

• TC (Transaction Coordinator) - 事务协调者：维护全局和分支事务的状态。
• TM (Transaction Manager) - 事务管理器：定义全局事务的范围。
• RM (Resource Manager) - 资源管理器：管理分支事务处理的资源。