3. 分布式事务基础理论
在 OAuth2.0 集成场景中，授权服务器、资源服务器与业务服务之间的状态一致性，本质上是分布式事务问题。理解 CAP、BASE、最终一致性、TCC 与 Saga，是设计安全架构的理论基石。
3.1 CAP 定理
CAP 定理（Brewer 定理）指出，分布式系统最多只能同时满足以下三个特性中的两个：
| 特性 | 说明 | OAuth2.0 场景示例 |
|---|---|---|
| C — 一致性 | 所有节点在同一时刻看到相同的数据 | 令牌撤销后，所有资源服务器立即拒绝该令牌 |
| A — 可用性 | 每个请求都能获得非错误的响应 | 授权服务即使部分节点故障，仍能返回令牌 |
| P — 分区容错性 | 系统在网络分区时仍能正常运行 | 授权服务与资源服务之间的网络中断不影响基本流程 |
架构启示： 在 OAuth2.0 分布式部署中，网络分区是常态，因此必须在 C 与 A 之间做权衡。令牌颁发通常选择 AP（可用性优先），令牌撤销则倾向于 CP（一致性优先）。
3.2 BASE 理论
BASE 理论是对 CAP 中 AP 策略的延伸，强调牺牲强一致性以换取可用性：
- BA — 基本可用：系统在故障时允许降级，但核心功能（如令牌验证）必须保持响应。
- S — 软状态：允许系统存在中间状态，例如令牌刚被撤销但缓存尚未刷新。
- E — 最终一致性：经过一段时间后，所有副本数据最终达到一致。
实践要点： 在 OAuth2.0 的令牌缓存场景中，资源服务器可以短暂接受已撤销的令牌（软状态），但通过短 TTL 和异步同步机制保证最终一致性。
3.3 最终一致性
最终一致性是分布式事务中最常用的弱一致性模型。在 OAuth2.0 集成中，典型场景包括：
- 令牌状态同步： 授权服务更新令牌状态后，通过消息队列通知所有资源服务器。
- 用户权限变更： 用户角色修改后，各服务异步刷新权限缓存。
- 会话注销： 单点登出事件通过事件总线传播到所有依赖服务。
| 一致性级别 | 延迟 | 适用场景 | OAuth2.0 示例 |
|---|---|---|---|
| 强一致性 | 高 | 令牌撤销、密码修改 | 立即拒绝所有旧令牌 |
| 最终一致性 | 低 | 令牌颁发、权限缓存 | 允许短暂使用旧权限 |
| 因果一致性 | 中 | 审计日志、事件溯源 | 按事件顺序处理令牌变更 |
3.4 TCC 模式
TCC（Try-Confirm-Cancel）是一种补偿型分布式事务模式，适用于短事务、高一致性的场景。在 OAuth2.0 集成中，可用于资源授权与令牌发放的原子操作。
注意： TCC 模式要求业务服务实现 Try、Confirm、Cancel 三个幂等接口，对业务侵入性较强。在 OAuth2.0 中，仅适用于对一致性要求极高的关键路径，如令牌撤销与资源授权。
3.5 Saga 模式
Saga 模式适用于长事务、跨多个微服务的场景，通过一系列本地事务 + 补偿事务来保证最终一致性。在 OAuth2.0 集成中，常用于用户注册、权限同步等跨服务流程。
| 特性 | Choreography Saga | Orchestration Saga | OAuth2.0 推荐 |
|---|---|---|---|
| 协调方式 | 事件驱动，服务间直接通信 | 中央协调器控制流程 | Orchestration |
| 耦合度 | 低 | 中 | 适合安全审计 |
| 补偿复杂度 | 高 | 低 | 中央协调便于监控 |
| 典型场景 | 简单线性流程 | 复杂分支流程 | 令牌生命周期管理 |
3.6 模式对比与选型
| 模式 | 一致性 | 事务时长 | 业务侵入 | OAuth2.0 适用场景 |
|---|---|---|---|---|
| TCC | 强 | 短 | 高 | 令牌撤销、资源授权 |
| Saga | 最终 | 长 | 中 | 用户注册、权限同步 |
| 消息队列 | 最终 | 异步 | 低 | 令牌状态广播 |
| 本地事务 | 强 | 短 | 低 | 单服务内操作 |
选型建议： 在 OAuth2.0 集成架构中，推荐采用混合策略——关键路径（令牌撤销、密码修改）使用 TCC 保证强一致性；非关键路径（权限缓存、审计日志）使用 Saga 或消息队列实现最终一致性，以平衡性能与安全。