1. 分布式事务概述
1.1 分布式事务的定义
分布式事务是指参与事务的多个操作分布在不同的网络节点（服务、数据库、消息队列等）上，但仍需保证这些操作满足 ACID 特性（原子性、一致性、隔离性、持久性）的事务处理模型。在单体架构中，本地数据库事务通过锁和日志机制即可实现 ACID；但在微服务、多数据源、跨网络调用的场景下，传统本地事务无法跨越进程边界，必须引入分布式事务协议来协调多个参与者的最终一致性。
核心矛盾：分布式系统的网络不可靠性与事务 ACID 的强一致性要求之间存在天然冲突。分布式事务的本质是在“可用性”与“一致性”之间寻找可接受的平衡点。
1.2 CAP 定理与 BASE 理论
CAP 定理
CAP 定理（由 Eric Brewer 提出）指出，一个分布式系统最多只能同时满足以下三个特性中的两个：
| 特性 | 说明 | 典型场景 |
|---|---|---|
| C — Consistency（一致性） | 所有节点在同一时刻看到的数据完全相同 | 银行转账、库存扣减 |
| A — Availability（可用性） | 每个请求都能获得非错误的响应（不保证数据最新） | CDN 缓存、商品浏览 |
| P — Partition Tolerance（分区容错性） | 系统在网络分区（节点间通信中断）时仍能正常运行 | 跨机房部署、云原生架构 |
由于网络分区在分布式系统中是必然发生的，因此实际设计时必须在 CP（放弃可用性）和 AP（放弃强一致性）之间做出选择。传统 2PC 属于 CP 模型，而 Saga 事务则属于 AP 模型。
BASE 理论
BASE 理论是对 CAP 中 AP 模型的延伸，强调“最终一致性”：
- BA — Basically Available（基本可用）：系统允许部分功能降级，但核心服务保持可用。
- S — Soft State（软状态）：允许系统存在中间状态，不要求时刻强一致。
- E — Eventually Consistent（最终一致性）：经过一段时间后，所有副本数据最终达到一致。
实践启示：Saga 事务正是 BASE 理论的典型实现——它不追求全局强一致，而是通过异步补偿机制保证业务最终一致，同时保持系统的高可用性。
1.3 分布式事务的常见解决方案
2PC（两阶段提交）
2PC 引入协调者（Coordinator）角色，将事务提交分为两个阶段：
- 准备阶段（Vote Phase）：协调者向所有参与者发送 prepare 请求，参与者执行本地事务但不提交，返回 Yes/No。
- 提交阶段（Commit Phase）：若所有参与者都返回 Yes，协调者发送 commit 指令；否则发送 rollback 指令。
主要缺陷：同步阻塞（参与者持有锁等待协调者指令）、单点故障（协调者宕机导致事务悬空）、数据不一致（第二阶段网络异常时部分参与者提交、部分回滚）。
TCC（Try-Confirm-Cancel）
TCC 将业务操作拆分为三个步骤，由业务层实现补偿逻辑：
| 阶段 | 操作 | 示例（订单+库存） |
|---|---|---|
| Try | 预留资源、检查业务条件 | 冻结库存数量、预占订单号 |
| Confirm | 真正执行业务（幂等） | 扣减冻结库存、生成正式订单 |
| Cancel | 释放预留资源（幂等） | 解冻库存、取消订单 |
TCC 相比 2PC 减少了锁持有时间，但要求业务接口必须实现幂等性和补偿逻辑，开发成本较高。
Saga 事务
Saga 是一种长事务解决方案，将一个全局事务拆分为多个本地子事务，每个子事务对应一个补偿操作（Compensation）。当某个子事务失败时，Saga 按照反向顺序依次执行补偿操作，回滚已提交的子事务。
- 核心思想：放弃全局锁，通过异步补偿实现最终一致性。
- 两种编排模式：
- Choreography（ choreography，编排）：各服务通过事件驱动相互协调，无中心协调者。
- Orchestration（编排，协调）：引入 Saga 协调器统一管理事务流程和补偿顺序。
- 适用场景：跨服务长流程、高并发业务、对实时一致性要求不高的场景（如订单创建、旅行预订）。
为什么 Saga 适合鉴权拦截场景？鉴权拦截通常涉及多个微服务的权限校验、令牌刷新、日志记录等操作，这些操作允许短暂的不一致状态（如令牌已刷新但日志未写入），且需要高可用性。Saga 的异步补偿机制恰好满足这类需求——先放行请求，再异步补偿失败的鉴权操作。
1.4 方案选型对比总结
| 维度 | 2PC | TCC | Saga |
|---|---|---|---|
| 一致性模型 | 强一致性 | 最终一致性 | 最终一致性 |
| 锁机制 | 全局锁（资源阻塞） | 业务预留锁 | 无锁 |
| 业务侵入性 | 低（数据库层实现） | 高（需实现 Try/Confirm/Cancel） | 中（需实现正向+补偿） |
| 容错能力 | 弱（协调者单点） | 中（需幂等保障） | 强（异步补偿+重试） |
| 典型场景 | 跨库转账、配置同步 | 库存扣减、账户扣款 | 订单流程、鉴权拦截 |