1. 缓存一致性概述
1.1 缓存一致性问题的定义
在分布式系统与容器化微服务架构中，缓存一致性（Cache Consistency）是指缓存层与数据源（如数据库、文件系统、外部API）之间的数据在任意时刻保持逻辑等价的状态。当业务数据发生变更时，缓存中的副本如果不能及时同步更新，就会产生缓存与数据源不一致的现象，导致下游服务读取到过期或错误的数据。
核心矛盾：缓存层追求高性能（低延迟、高吞吐），数据源追求高可靠（持久化、事务性）。两者之间的同步延迟与更新顺序差异，是缓存一致性问题的根本来源。
在容器化部署场景中，由于实例数量动态伸缩、网络拓扑频繁变化、配置中心与注册中心解耦，缓存一致性问题被进一步放大。常见的缓存不一致场景包括：
- 写后读不一致：应用先更新数据库，但缓存未及时失效或更新，后续请求读取到旧缓存。
- 并发写冲突：多个容器实例同时更新同一缓存键，导致脏写或丢失更新。
- 缓存穿透与雪崩：缓存失效后大量请求直接打到数据库，加剧数据源压力并延长不一致窗口。
- 跨服务缓存漂移：不同微服务各自维护本地缓存，全局数据变更无法广播到所有副本。
1.2 CAP理论在缓存中的应用
CAP理论（Consistency, Availability, Partition Tolerance）是分布式系统设计的基石。在缓存系统中，三个属性的权衡直接决定了缓存一致性策略的选择：
| 属性 | 定义 | 在缓存中的体现 |
|---|---|---|
| C（一致性） | 所有节点在同一时刻看到相同的数据副本 | 缓存集群中所有副本必须同步更新，读请求返回最新写入值 |
| A（可用性） | 非故障节点在合理时间内返回合理响应 | 缓存节点即使发生网络分区，仍能对外提供读取服务 |
| P（分区容错性） | 系统在网络分区时仍能正常运行 | 缓存集群跨容器节点、跨可用区部署时，分区是常态 |
根据CAP定理，缓存系统最多只能同时满足其中两项。在实际容器化部署中，P（分区容错性）是必须保证的，因此设计者需要在C与A之间做出取舍：
- CP系统（放弃A）：优先保证缓存一致性，网络分区时暂停写入或拒绝服务。适用于金融交易、库存扣减等强一致性场景。
- AP系统（放弃C）：优先保证缓存可用性，允许短暂的不一致窗口，通过后台异步同步最终达成一致。适用于商品详情、用户会话等可容忍延迟的场景。
容器化实践建议：在Kubernetes集群中，缓存组件（如Redis Sentinel/Cluster）通常部署为StatefulSet，利用Headless Service保证节点间网络标识稳定。此时P是默认满足的，重点在于根据业务需求配置C与A的权重。
1.3 最终一致性与强一致性对比
在缓存一致性策略中，强一致性（Strong Consistency）与最终一致性（Eventual Consistency）是两种最典型的模型。理解它们的差异，是设计缓存一致性闭环方案的前提。
| 对比维度 | 强一致性 | 最终一致性 |
|---|---|---|
| 定义 | 写入操作完成后，后续任何读操作都能立即读取到最新值 | 写入操作完成后，系统保证在没有新写入的情况下，所有副本最终会达到一致状态 |
| 延迟要求 | 读操作必须等待所有副本同步完成 | 读操作可以立即返回，允许短暂的不一致窗口 |
| 实现机制 | 同步复制、分布式锁、两阶段提交（2PC） | 异步复制、消息队列、后台补偿任务 |
| 性能影响 | 写入延迟高，吞吐量受限 | 写入延迟低，吞吐量高 |
| 适用场景 | 订单状态、库存扣减、支付流水 | 用户资料、商品详情、推荐列表 |
| 容器化挑战 | Pod重启/迁移时锁状态丢失，网络抖动导致同步阻塞 | 消息丢失或重复消费，副本同步延迟不可控 |
注意：在容器化环境中，强一致性方案对网络稳定性要求极高。如果Redis集群跨Kubernetes节点部署，节点间网络延迟波动可能导致同步超时，进而引发一致性协议阻塞。建议在关键业务路径上使用本地读修复或租约机制来降低强一致性的副作用。
两种模型在实际工程中并非完全对立。很多缓存系统采用混合策略：对核心数据使用强一致性（如通过Redis RedLock实现分布式锁），对非核心数据使用最终一致性（如通过Kafka异步同步缓存失效消息）。这种分层设计在容器化部署中尤为常见。
1.4 缓存一致性闭环的必要性
在容器化微服务架构中，缓存一致性不是一次性的配置工作，而是一个需要持续监控、自动修复、闭环反馈的工程体系。单纯依赖缓存过期时间或手动刷新，无法应对Pod漂移、网络分区、配置变更等动态场景。因此，本课程后续章节将围绕以下闭环能力展开：
- 检测：通过一致性校验任务定期对比缓存与数据源的数据指纹。
- 修复：自动触发缓存失效、回源加载或增量同步。
- 验证：确认修复后数据一致，并记录不一致事件用于复盘。
- 优化：根据历史不一致模式调整缓存策略、超时参数与同步频率。