2. 核心概念：本地事务、分布式事务、两阶段提交(2PC)与Saga模式对比
在深入Outbox模式之前，必须厘清分布式系统中最核心的事务概念。本章将系统性地对比本地事务、分布式事务、两阶段提交(2PC)与Saga模式，帮助你在鉴权拦截场景中做出正确的技术选型。
2.1 本地事务：单机原子性的基石
本地事务（Local Transaction）作用于单一数据库或单一资源管理器，遵循ACID原则。在微服务架构中，每个服务内部的数据库操作通常由本地事务保证一致性。
| 特性 | 说明 | 鉴权场景示例 |
|---|---|---|
| 原子性 | 事务内的所有操作要么全部成功，要么全部回滚 | 插入Token记录与更新用户最后登录时间必须同时完成 |
| 一致性 | 事务前后数据满足所有约束 | Token状态字段不能出现非法值 |
| 隔离性 | 并发事务互不干扰 | 同一用户不能同时生成两个有效Token |
| 持久性 | 提交后数据永久保存 | 鉴权日志写入后不因宕机丢失 |
实践要点：在Outbox模式中，业务操作与Outbox消息写入必须在同一个本地事务中完成，这是保证"至少一次交付"的前提。
2.2 分布式事务：跨服务的挑战
分布式事务（Distributed Transaction）涉及多个独立资源管理器（数据库、消息队列、缓存等），需要跨网络协调。在鉴权拦截场景中，一次登录可能涉及认证服务、用户服务、审计服务等多个节点。
分布式事务面临的核心挑战：
- 网络不确定性：消息延迟、丢失、重复
- 部分失败：部分节点成功、部分节点失败
- 一致性窗口：节点间数据同步存在时间差
- 协调开销：需要额外的协调者组件
2.3 两阶段提交(2PC)：强一致性的经典方案
两阶段提交（Two-Phase Commit, 2PC）是最经典的分布式事务协议，通过引入协调者（Coordinator）实现跨节点的原子提交。
核心流程：2PC将事务提交分为"准备阶段"和"提交阶段"，所有参与者必须统一投票。
2PC的局限性：
- 同步阻塞：准备阶段锁定资源，影响并发性能
- 单点故障：协调者宕机可能导致事务悬空
- 数据不一致风险：第二阶段部分参与者提交失败时难以回滚
- 不适合长事务：锁持有时间随参与者数量线性增长
2.4 Saga模式：补偿型事务的实践
Saga模式将长事务拆分为一系列本地事务，每个本地事务对应一个补偿操作。当某个步骤失败时，通过反向执行补偿操作来撤销已生效的变更。
| 维度 | 2PC | Saga模式 |
|---|---|---|
| 一致性模型 | 强一致性（ACID） | 最终一致性（BASE） |
| 资源锁定 | 持有锁直到全局提交/回滚 | 不持有锁，提交即释放 |
| 事务时长 | 短事务（秒级） | 可支持长事务（分钟/小时级） |
| 协调方式 | 中心化协调者 | 编排(Choreography)或协调(Orchestration) |
| 失败处理 | 自动回滚 | 执行补偿操作 |
| 适用场景 | 金融转账、库存扣减 | 订单流程、鉴权拦截、内容发布 |
2.5 四种事务模式对比总览
2.6 鉴权拦截场景的选型建议
核心结论：在分布式鉴权拦截场景中，Saga模式 + Outbox模式是最佳组合。2PC的强一致性虽然诱人，但其同步阻塞和单点故障特性在高并发鉴权场景中难以接受。
选型决策流程：
- 单服务鉴权：使用本地事务即可，无需引入分布式方案
- 跨服务鉴权（低延迟要求）：采用Saga编排模式，配合Outbox保证消息可靠投递
- 跨服务鉴权（强一致性要求）：考虑2PC，但需评估性能影响和故障处理复杂度
- 混合场景：核心鉴权链路使用Saga，辅助操作（如日志、审计）使用异步消息