📚 课程目录第2章缓存一致性基础

2. 缓存一致性基础：CAP理论在缓存场景的体现

在分布式缓存系统中，CAP理论是理解一致性取舍的基石。缓存作为加速数据访问的中间层，天然面临分区容忍性（P）的挑战——当网络分区发生时，缓存节点与数据库之间的数据同步可能中断。此时，系统必须在一致性（C）和可用性（A）之间做出选择。

  核心观点：缓存一致性不是“全有或全无”的二元选择，而是根据业务场景在强一致性、最终一致性和弱一致性之间进行权衡。OpenAPI契约需要明确声明缓存的一致性级别，以便客户端和服务端对齐预期。

2.1 强一致性（Strong Consistency）

定义：在强一致性模型下，任何一次读操作都能读到某个数据最新的写入结果。对于缓存系统而言，这意味着缓存中的数据必须与数据库中的数据保持实时同步，所有副本在写入完成后立即一致。

特性	说明	典型实现
写入延迟	高，需要等待所有副本确认	同步双写、分布式锁
读取性能	稳定，无脏读风险	缓存穿透保护、一致性哈希
可用性风险	节点故障可能导致写入失败	Paxos/Raft 共识算法
适用场景	金融交易、库存扣减、配置中心	Redis 集群 + WAIT 命令

实践提示：在OpenAPI契约中，强一致性缓存接口应使用 @CacheConsistency(level = STRONG) 注解或 x-cache-consistency: strong 扩展属性，并配合 Cache-Control: no-cache 响应头，防止客户端使用过期缓存。

2.2 最终一致性（Eventual Consistency）

定义：最终一致性保证如果没有新的写入操作，经过一段时间的“收敛窗口”后，所有副本最终会达到一致状态。在缓存场景中，写入操作先更新数据库，然后异步刷新缓存，允许在短时间内出现缓存与数据库不一致。

特性	说明	典型实现
写入延迟	低，仅需更新主副本	异步消息队列、CDC（变更数据捕获）
读取性能	高，缓存命中率优先	Cache-Aside 模式、读写分离
不一致窗口	毫秒到秒级，可配置	TTL 过期、版本号对比
适用场景	社交动态、商品详情、用户资料	Redis + Canal + Binlog

避坑指南：最终一致性不等于“不处理一致性问题”。必须定义明确的收敛时间（如 x-cache-max-stale: 5s），并在OpenAPI文档中声明 x-cache-consistency: eventual 和 x-cache-convergence-window: 5000，让调用方知晓可能读到过期数据。

2.3 弱一致性（Weak Consistency）

定义：弱一致性不保证任何时间点上的数据一致性。写入操作成功后，后续的读操作可能返回旧值，且没有明确的收敛保证。在缓存场景中，弱一致性通常用于对实时性要求极低的非关键数据。

特性	说明	典型实现
写入延迟	极低，无需同步	本地缓存、浏览器缓存
读取性能	最高，完全避免缓存失效	HTTP 强缓存、CDN 边缘节点
一致性保证	无，数据可能长期不一致	无版本控制、无回源校验
适用场景	静态资源、公告信息、非关键计数	Nginx 缓存、Service Worker

2.4 三种一致性模型的对比与选择

2.5 一致性模型的选择决策树

在实际的缓存系统设计中，可以根据以下决策树快速选择合适的一致性模型：

数据是否允许短暂不一致？
- 是 → 进入第2步
- 否 → 选择强一致性（如：账户余额、库存扣减）
不一致窗口是否有明确上限？
- 是 → 选择最终一致性（如：商品详情、用户动态）
- 否 → 进入第3步
数据是否可容忍长期不一致？
- 是 → 选择弱一致性（如：静态资源、公告信息）
- 否 → 重新评估业务需求，考虑引入补偿机制

  OpenAPI契约落地建议：在API定义中，使用 x-cache-consistency 扩展属性明确声明一致性级别，并配合 x-cache-convergence-window（最终一致性）或 x-cache-strong-read（强一致性）等参数，让API消费者能够根据自身需求做出正确的调用决策。

2.6 一致性模型在OpenAPI中的表达示例

openapi: 3.0.3
info:
  title: 商品缓存服务
  version: 1.0.0
paths:
  /products/{id}:
    get:
      summary: 获取商品详情
      parameters:
        - name: x-cache-consistency
          in: header
          schema:
            type: string
            enum: [strong, eventual, weak]
            default: eventual
          description: 客户端期望的缓存一致性级别
      responses:
        '200':
          description: 成功响应
          headers:
            x-cache-hit:
              schema:
                type: boolean
            x-cache-stale:
              schema:
                type: integer
                description: 缓存过期时间（秒），仅最终一致性时返回
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Product'
      x-cache-consistency: eventual
      x-cache-convergence-window: 5000
      x-cache-ttl: 300

通过上述OpenAPI扩展属性，缓存中间件可以自动根据声明的一致性级别选择合适的缓存策略，实现从API契约到缓存行为的端到端治理。