1. 分布式事务基础：CAP理论、BASE理论、最终一致性概念
在微服务与分布式系统架构中，事务处理从单机ACID走向分布式CAP/BASE，是理解鉴权拦截与参数调优的前提。本节从三个核心理论入手，建立分布式事务的认知基线。
1.1 CAP理论：分布式系统的“不可能三角”
CAP理论由Eric Brewer于2000年提出，是分布式系统设计的根本约束。它指出一个分布式系统最多只能同时满足以下三个特性中的两个：
| 特性 | 英文 | 说明 | 典型场景 |
|---|---|---|---|
| 一致性 | Consistency | 所有节点在同一时刻看到相同的数据副本 | 银行转账、库存扣减 |
| 可用性 | Availability | 每次请求都能获得非错误的响应（不保证数据最新） | CDN、搜索引擎 |
| 分区容错性 | Partition Tolerance | 系统在网络分区（节点间通信中断）时仍能正常运行 | 跨机房部署、云原生集群 |
关键认知： 在分布式环境中，网络分区是必然发生的，因此P必须被满足。实际设计是在CP（强一致）与AP（高可用）之间做权衡。例如，ZooKeeper选择CP，Eureka选择AP。
1.2 BASE理论：对CAP的务实延伸
BASE理论由eBay架构师Dan Pritchett提出，是对AP模式的实践总结。它放弃了强一致性，允许系统在一段时间内处于不一致状态，但最终会达到一致。
- BA — Basically Available（基本可用）：系统在出现故障时允许损失部分功能，但核心服务仍可用。例如，电商大促时降级“历史订单查询”功能。
- S — Soft State（软状态）：允许系统在不同节点间存在中间状态，数据副本的同步存在延迟。
- E — Eventually Consistent（最终一致性）：在没有新写入后，经过足够长的时间，所有副本最终会达到一致状态。
实战启示： 在鉴权拦截场景中，如果使用分布式会话（如Redis Session），当Redis集群发生分区时，系统应优先保证登录鉴权可用（AP），允许短暂的用户权限缓存不一致，待分区恢复后自动同步。
1.3 最终一致性：分布式事务的落地基石
最终一致性是BASE理论的核心，也是大多数分布式事务方案（如TCC、Saga、消息事务）的底层保证。根据一致性的严格程度，最终一致性可分为以下级别：
| 级别 | 描述 | 延迟容忍 | 典型应用 |
|---|---|---|---|
| 因果一致性 | 如果进程A通知进程B它已更新数据，则B的后续读操作必须看到该更新；其他进程无此约束 | 低 | 社交评论、协作编辑 |
| 读己之所写 | 用户总能读到自己的最新写入，但其他用户可能读到旧数据 | 低 | 用户个人设置、购物车 |
| 会话一致性 | 在同一会话内，保证读己之所写；跨会话无保证 | 中 | Web登录态、API Session |
| 单调读一致性 | 如果进程在某个时间点读到某个值，后续读操作不会读到更旧的值 | 中 | 配置中心、版本管理 |
| 单调写一致性 | 写操作按顺序执行，后发起的写不会覆盖先发起的写 | 高 | 订单状态机、流水记录 |
1.4 从理论到实战：CAP/BASE在鉴权拦截中的映射
在分布式鉴权拦截系统中，每一次请求都需要验证用户身份与权限。如果底层依赖的认证中心或权限缓存出现分区，系统必须做出CAP选择：
- CP策略（强一致）：等待认证中心恢复，期间拒绝请求。适用于金融转账、敏感操作。
- AP策略（最终一致）：使用本地缓存或降级策略，允许短时权限偏差，保证服务可用。适用于内容浏览、非关键查询。
参数调优关联： 后续章节中，鉴权拦截器的缓存过期时间、重试次数、降级开关等参数，本质上都是在控制“最终一致性”的窗口大小。窗口越小，一致性越强，但可用性越低；窗口越大，可用性越高，但数据偏差风险越大。
1.5 知识结构总结
| 理论 | 核心主张 | 对分布式事务的指导 | 对鉴权拦截的启示 |
|---|---|---|---|
| CAP | C、A、P三者不可兼得 | 明确事务方案的选择边界 | 决定鉴权是强一致还是最终一致 |
| BASE | 基本可用 + 软状态 + 最终一致 | 允许中间状态，接受延迟 | 缓存降级、异步同步策略 |
| 最终一致性 | 无新写入后，副本最终一致 | TCC/Saga/消息事务的理论基础 | 鉴权缓存TTL、重试机制设计 |