3. 分布式事务基础理论：CAP、BASE、2PC、3PC、TCC 与 Saga
在 Kubernetes 环境下构建分布式鉴权拦截系统，事务一致性是核心挑战。本章系统梳理分布式事务的六大基础理论，为后续配置热更新中的一致性设计奠定理论基础。
3.1 CAP 定理：分布式系统的“不可能三角”
CAP 定理（Brewer’s Theorem）指出，分布式系统最多只能同时满足以下三个特性中的两个：
| 特性 | 全称 | 说明 | 鉴权场景示例 |
|---|---|---|---|
| C | Consistency（一致性） | 所有节点在同一时刻看到相同的数据 | 鉴权规则更新后，所有 Pod 立即生效 |
| A | Availability（可用性） | 每个请求都能获得非错误的响应 | 鉴权服务始终返回允许/拒绝，不超时 |
| P | Partition Tolerance（分区容错性） | 系统在网络分区时仍能正常运行 | 鉴权中心与配置中心网络中断时仍可决策 |
关键结论： 在分布式系统中，网络分区（P）是必然发生的，因此设计者必须在 C 与 A 之间做出权衡。Kubernetes 鉴权拦截系统通常选择 AP 或 CP 模型，取决于业务对一致性的容忍度。
3.2 BASE 理论：最终一致性的实践指南
BASE 理论是对 CAP 中 AP 模型的延伸，强调系统在可用性和分区容错的前提下，通过“最终一致性”来弥补强一致性的缺失。
- BA — Basically Available（基本可用）：系统允许部分功能降级，但核心服务始终可用。例如鉴权拦截失败时，可降级为“默认拒绝”策略。
- S — Soft State（软状态）：允许数据存在中间状态，不要求强一致。例如配置更新过程中，部分 Pod 使用旧规则、部分使用新规则。
- E — Eventually Consistent（最终一致）：经过一段时间后，所有副本数据最终达到一致。例如配置热更新最终在所有 Pod 上生效。
Kubernetes 实践提示： 鉴权配置的热更新天然符合 BASE 模型。ConfigMap 更新后，Pod 通过 watch 机制异步拉取，存在短暂的不一致窗口，但最终所有副本会收敛到最新配置。
3.3 2PC（两阶段提交）：强一致性的经典方案
2PC 通过引入协调者（Coordinator）将事务提交分为两个阶段，确保所有参与者要么全部提交，要么全部回滚。
| 阶段 | 步骤 | 协调者行为 | 参与者行为 |
|---|---|---|---|
| 阶段一：准备 | 1. 发送准备请求 2. 执行本地事务 3. 返回投票 |
向所有参与者发送 prepare 请求 | 执行事务但不提交，记录 undo/redo 日志，返回 Yes/No |
| 阶段二：提交/回滚 | 4. 收集投票 5. 发送决策 6. 执行决策 |
全部 Yes → 发送 commit；任一 No → 发送 abort | 收到 commit 后提交事务；收到 abort 后回滚 |
2PC 的缺陷： 同步阻塞（参与者等待协调者决策）、单点故障（协调者宕机导致事务悬挂）、数据不一致（协调者发送部分 commit 后宕机）。在 Kubernetes 鉴权场景中，2PC 的强一致性代价过高，通常不推荐。
3.4 3PC（三阶段提交）：缓解阻塞问题
3PC 在 2PC 的基础上引入“预提交”阶段和超时机制，降低阻塞范围。
- CanCommit（询问阶段）：协调者询问参与者是否可以执行事务，参与者仅做可行性检查，不执行任何操作。
- PreCommit（预提交阶段）：协调者发送预提交请求，参与者执行事务并写入日志，但暂不提交。
- DoCommit（提交阶段）：协调者发送最终提交或中止指令，参与者执行提交或回滚。
3PC 通过引入超时机制，使参与者在超时后自动中止事务，避免 2PC 中的无限阻塞。但 3PC 仍无法完全解决数据一致性问题，且协议复杂度显著增加。
3.5 TCC（Try-Confirm-Cancel）：业务补偿模式
TCC 是一种基于业务逻辑的分布式事务方案，将每个事务操作拆分为三个阶段：
| 阶段 | 操作 | 鉴权拦截场景示例 |
|---|---|---|
| Try | 预留资源、检查业务条件 | 检查鉴权规则是否可用，锁定规则版本号 |
| Confirm | 执行真正的业务操作 | 应用新鉴权规则到拦截器，更新内存缓存 |
| Cancel | 回滚 Try 阶段预留的资源 | 释放规则版本锁，回退到上一版本 |
适用场景： TCC 适用于对一致性要求较高、且业务逻辑支持补偿操作的场景。在鉴权配置热更新中，TCC 可用于确保“规则版本切换”的原子性：Try 阶段锁定新旧版本，Confirm 阶段切换生效，Cancel 阶段回滚。
3.6 Saga 模式：长事务的最终一致性方案
Saga 模式将一个分布式事务拆分为一系列本地事务，每个本地事务对应一个补偿事务。Saga 有两种执行方式：
- Choreography（编排模式）：每个服务完成本地事务后，触发下一个服务的事务。无中心协调者，通过事件驱动。
- Orchestration（编排模式）：引入 Saga 协调器，由协调器统一调度各服务的执行顺序和补偿逻辑。
Saga 在鉴权热更新中的优势： 配置更新涉及多个微服务（规则校验、缓存刷新、日志记录），Saga 模式允许每个服务独立提交本地事务，并通过补偿机制回滚失败步骤，避免长事务锁定资源。在 Kubernetes 环境下，Saga 协调器可部署为独立的 Deployment，利用 Service 进行服务发现。
3.7 六种理论对比总结
| 理论/协议 | 一致性模型 | 是否阻塞 | 容错能力 | 适用场景 |
|---|---|---|---|---|
| CAP | 理论框架 | — | — | 指导系统设计取舍 |
| BASE | 最终一致性 | 否 | 高 | 互联网高可用系统 |
| 2PC | 强一致性 | 是 | 低 | 数据库跨节点事务 |
| 3PC | 强一致性 | 部分阻塞 | 中 | 对阻塞敏感的场景 |
| TCC | 最终一致性 | 否 | 高 | 业务补偿明确的场景 |
| Saga | 最终一致性 | 否 | 高 | 长事务、跨微服务 |