📚 课程目录第1章缓存一致性概述

1. 缓存一致性概述

1.1 缓存一致性问题的定义

缓存一致性（Cache Consistency）是指在分布式系统中，缓存层与数据源（如数据库）之间的数据保持同步的程度。当应用程序对数据源进行写操作后，缓存中对应的旧副本必须被更新或失效，否则后续读请求将获取到过时数据，导致业务逻辑错误。

从工程角度看，缓存一致性问题的核心矛盾在于：缓存通过牺牲强一致性来换取低延迟和高吞吐。一旦引入缓存，系统就天然存在一个短暂的时间窗口——在这个窗口内，缓存与数据库中的数据可能不一致。

  关键指标： 缓存一致性通常用 staleness window（陈旧窗口） 来衡量，即从数据库写入完成到缓存感知该变更之间的时间差。窗口越小，一致性越强，但系统复杂度和开销也越高。

1.2 CAP 理论在缓存中的体现

CAP 理论指出，分布式系统在 一致性（Consistency）、可用性（Availability） 和 分区容错性（Partition Tolerance） 三者之间最多只能同时满足两个。缓存系统作为分布式数据访问的关键组件，其设计选择直接受 CAP 约束：

CAP 维度	缓存中的具体表现	典型场景
C — 一致性	所有节点在同一时刻看到相同的数据副本；缓存写入后，所有读请求必须返回最新值	金融交易、库存扣减
A — 可用性	缓存服务始终可响应，即使部分节点故障或网络分区，读请求仍能返回数据（可能是旧数据）	商品详情页、内容分发
P — 分区容错性	缓存集群在网络分区时仍能继续工作；Kubernetes 环境下网络故障是常态，P 不可舍弃	跨可用区部署、节点宕机

在分布式缓存实践中，P 是必选项——网络分区在 Kubernetes 集群中频繁发生（Pod 迁移、节点故障、网络策略变更）。因此，缓存架构师只能在 CP（牺牲可用性保证强一致） 和 AP（牺牲一致性保证高可用） 之间做选择。绝大多数互联网业务选择 AP，通过最终一致性模型和补偿机制来容忍短暂的不一致。

工程经验： 在 Kubernetes 环境下，不要试图构建强一致的分布式缓存（如使用分布式锁+同步写穿透），这会严重降低 Pod 的弹性伸缩能力和故障恢复速度。优先采用 Read-Through + 异步失效 的 AP 模型。

1.3 为什么 Kubernetes 环境下缓存一致性更复杂

Kubernetes 的声明式编排、动态调度和网络模型给缓存一致性带来了传统物理机或虚拟机部署中不存在的挑战。以下是四个核心复杂性来源：

Pod 生命周期不可预测：缓存 Pod 随时可能因滚动更新、资源驱逐、节点故障而重建。重建后缓存为空，产生 缓存雪崩 风险；同时旧 Pod 持有的本地缓存数据丢失，导致一致性窗口扩大。
服务发现与流量漂移：Kubernetes Service 的负载均衡基于 iptables/IPVS，请求可能被路由到任意一个缓存 Pod。如果缓存分片策略依赖客户端哈希（如一致性哈希），Pod 扩缩容会导致大量缓存 miss 和 惊群效应。
网络策略与延迟抖动：CNI 插件（Calico、Cilium）引入的网络策略、Service Mesh（Istio）的 sidecar 代理，都会增加缓存请求的延迟和失败率。网络分区时，缓存节点间的同步协议（如 Gossip）可能超时，导致数据不一致。
多副本与状态同步：Kubernetes 鼓励无状态设计，但缓存本身是有状态的。当缓存以 StatefulSet 部署多副本时，副本间的数据同步、Leader 选举、故障转移都需要额外的一致性保障机制。

常见陷阱： 很多团队在 Kubernetes 上直接复用传统 Redis Sentinel 或 Cluster 方案，忽略了 Pod IP 动态变化对哨兵监控和客户端连接池的影响。结果在 Pod 重启后，客户端仍然连接旧 IP，导致缓存穿透和一致性问题。

1.4 缓存一致性模型分类

在进入具体治理方案之前，需要明确缓存一致性的三种基本模型。不同模型对应不同的业务容忍度和实现成本：

模型	定义	陈旧窗口	典型实现	K8s 适用性
强一致性	缓存写入后，所有后续读立即看到最新值	0	同步写穿透 + 分布式锁	低（锁竞争影响 Pod 弹性）
最终一致性	缓存最终会与数据库一致，但存在短暂不一致窗口	毫秒~秒级	异步失效 + TTL + 补偿	高（无状态，易伸缩）
弱一致性	不保证缓存与数据库一致，依赖业务自行校验	不确定	Cache-Aside + 定期刷新	中（需业务容忍脏读）

推荐策略： 在 Kubernetes 生产环境中，优先采用 最终一致性 + 主动失效 的组合。通过消息队列广播缓存失效事件，配合合理的 TTL 兜底，可以在保证高可用的同时将不一致窗口控制在 100ms 以内。