1. 分布式事务概述
1.1 什么是分布式事务
分布式事务是指涉及多个独立数据库、服务或节点的事务操作，这些操作必须满足“要么全部成功，要么全部失败”的原子性约束。在单体架构中，事务由本地数据库的 ACID 特性保证；而在分布式环境下，事务的参与者分布在不同的网络节点上，需要额外的协调机制来保证数据一致性。
核心定义：分布式事务 = 跨多个独立数据节点的一组操作，这些操作作为一个逻辑工作单元，整体提交或整体回滚。
分布式事务的典型特征包括：
- 跨节点：事务参与者位于不同的进程、主机或数据中心。
- 异构性：参与者可能使用不同的数据库、消息队列或存储系统。
- 网络不确定性：节点间通信存在延迟、超时、丢包等风险。
- 协调复杂性：需要全局协调者（Coordinator）来管理事务生命周期。
1.2 CAP 定理与 BASE 理论
CAP 定理
CAP 定理（Brewer's Theorem）是分布式系统的基石，它指出一个分布式系统最多只能同时满足以下三个特性中的两个：
| 特性 | 全称 | 说明 |
|---|---|---|
| C | Consistency（一致性） | 所有节点在同一时刻看到相同的数据 |
| A | Availability（可用性） | 每个请求都能获得非错误的响应 |
| P | Partition Tolerance（分区容错性） | 系统在网络分区时仍能正常运行 |
由于网络分区（P）在分布式系统中不可避免，实际设计时通常需要在 C 和 A 之间做出权衡：
- CP 系统：优先保证一致性，牺牲可用性。例如 ZooKeeper、etcd。
- AP 系统：优先保证可用性，牺牲强一致性。例如 Cassandra、DynamoDB。
- CA 系统：理论上不存在，因为分区必然发生。
BASE 理论
BASE 理论是对 CAP 定理中 AP 策略的实践总结，它放宽了对强一致性的要求，追求最终一致性：
| 缩写 | 全称 | 含义 |
|---|---|---|
| BA | Basically Available（基本可用） | 系统允许部分功能降级，但核心服务保持可用 |
| S | Soft State（软状态） | 允许数据中间状态，不要求时刻强一致 |
| E | Eventually Consistent（最终一致性） | 经过一段时间后，所有副本数据最终达到一致 |
实践启示：在分布式事务设计中，BASE 理论指导我们接受短暂的不一致窗口，通过补偿机制（如 Saga、TCC）在业务层面保证最终一致性，而不是追求传统 ACID 的强一致性。
1.3 分布式事务的挑战与场景
核心挑战
分布式事务面临的主要技术挑战可以归纳为以下五个方面：
- 网络不可靠：消息延迟、丢包、乱序、超时导致事务状态不确定。
- 节点故障：参与者宕机、重启、磁盘损坏导致事务中断。
- 数据一致性：跨节点数据在并发读写、故障恢复时可能出现不一致。
- 性能开销：协调通信、锁竞争、日志持久化显著增加延迟。
- 调试与监控：分布式链路追踪困难，事务状态难以全局可视化。
典型应用场景
分布式事务在以下业务场景中尤为常见：
| 场景 | 描述 | 示例 |
|---|---|---|
| 电商下单 | 扣库存、生成订单、扣减账户余额必须原子执行 | 用户下单后库存扣减失败需回滚订单 |
| 金融转账 | 跨账户、跨银行的资金划转要求强一致性 | A 账户扣款成功，B 账户入账失败需回滚 |
| 微服务编排 | 多个微服务协同完成一个业务操作 | 订单服务调用支付服务、物流服务、通知服务 |
| 数据同步 | 跨数据库、跨数据中心的增量数据同步 | 主库写入后同步到多个从库或缓存 |
| SaaS 多租户 | 租户数据分布在不同的物理库中 | 创建租户时需在多个分库中初始化数据 |
避坑提示：不要在所有跨服务调用中都使用分布式事务。对于非关键路径、可容忍短暂不一致的场景，优先考虑异步消息 + 补偿机制，避免不必要的性能损耗和复杂度。
技术选型决策树
在实际项目中，选择分布式事务方案通常遵循以下决策逻辑：
- 是否需要强一致性？ → 是：考虑 XA/2PC；否：考虑 TCC、Saga、本地消息表。
- 是否允许回滚？ → 是：TCC 或 Saga 补偿；否：最终一致性 + 异步对账。
- 性能要求高？ → 是：避免 2PC 阻塞协议，选择 Saga 或消息驱动。
- 异构系统多？ → 是：优先选择无侵入的 Saga 或本地消息表方案。
本章为后续深入学习分布式事务的各类实现方案（2PC、TCC、Saga、本地消息表、Seata 等）奠定了理论基础。理解 CAP 与 BASE 的权衡，以及分布式事务面临的真实挑战，是正确选型和设计事务边界的前提。