4. 缓存一致性问题定义

在分布式系统中引入缓存，本质上是用冗余数据换取访问速度。当缓存中的数据与后端数据库（或源服务）中的数据出现差异时，就产生了缓存一致性问题。理解这一问题的定义、典型场景以及一致性模型，是设计可靠缓存策略的前提。

4.1 什么是缓存一致性

缓存一致性（Cache Consistency）是指：对于同一份数据，缓存中的副本与数据源（如数据库、上游服务）中的主本在逻辑上保持等价。当数据源发生变更时，缓存副本必须在可接受的时间窗口内同步更新或失效，否则系统将返回过时（Stale）或错误的数据。

4.2 数据不一致的典型场景

在实际的 gRPC 微服务调用链中，以下三种场景最容易引发缓存不一致：

4.2.1 写后读不一致详解

这是最常见的缓存一致性问题。以 gRPC 更新用户信息为例：

1. 客户端 A 调用 UpdateUser() gRPC 方法，成功更新数据库中的用户昵称。
2. 缓存中仍保留旧昵称（未主动失效或更新）。
3. 客户端 B 调用 GetUser() gRPC 方法，缓存命中，返回旧昵称。
4. 客户端 B 看到的是过时数据，直到缓存 TTL 过期或手动失效。

4.2.2 并发写不一致详解

当多个 gRPC 请求并发修改同一数据时，缓存与数据库的更新顺序可能交错，导致最终状态不一致。

// 并发写导致缓存与数据库不一致的伪代码示例
// 线程1：扣减库存
cache.decrement("stock:item100", 1);   // 缓存扣减成功，剩余 9
db.execute("UPDATE stock SET count=count-1 WHERE id=100"); // 数据库扣减成功

// 线程2：扣减库存（与线程1几乎同时）
cache.decrement("stock:item100", 1);   // 缓存扣减成功，剩余 8
db.execute("UPDATE stock SET count=count-1 WHERE id=100"); // 数据库扣减成功

// 如果线程2的数据库操作先于线程1提交，最终缓存为8，数据库为9 → 不一致

这种场景在 gRPC 流式处理、批量库存扣减、秒杀系统中尤为突出。

4.3 强一致性与最终一致性

根据系统对一致性的容忍程度，缓存一致性模型分为两个极端：

4.4 缓存一致性模型对比图

下图展示了强一致性与最终一致性在数据流上的核心差异：

4.5 一致性模型选择决策树

在实际的 gRPC 服务设计中，可以根据以下条件快速选择一致性模型：

• 是否允许短暂读到旧数据？
  • 是 → 使用最终一致性（推荐默认选择）
  • 否 → 进入下一步判断
• 写后立即读的概率是否极高？
  • 是 → 使用强一致性（如支付回调、库存扣减）
  • 否 → 使用最终一致性 + 缓存预热即可
• 数据不一致是否会导致资损或安全风险？
  • 是 → 必须使用强一致性，甚至考虑放弃缓存直接读库
  • 否 → 最终一致性 + 监控告警即可