1. 缓存一致性概述
1.1 缓存一致性问题定义
缓存一致性（Cache Consistency）是指在分布式系统中，缓存层与底层数据源（如数据库）之间，以及多个缓存副本之间，数据保持相同状态的程度。当缓存中的数据与源数据出现差异时，即发生了缓存不一致。
核心定义：缓存一致性 = 缓存中的数据在任何时刻都与数据源中的数据保持逻辑等价，且所有缓存副本对同一数据的读取结果相同。
从系统视角看，缓存一致性包含两个维度：
| 维度 | 描述 | 典型问题 |
|---|---|---|
| 纵向一致性 | 缓存与数据库之间的数据同步 | 缓存未更新、缓存穿透 |
| 横向一致性 | 多级缓存或分布式缓存节点之间的数据同步 | 缓存副本间数据不一致 |
1.2 为什么需要缓存一致性
在引入缓存（尤其是 Redis）后，系统性能得到显著提升，但数据一致性成为必须面对的核心挑战。以下是需要缓存一致性的关键原因：
- 业务正确性保障：用户读取到过期或错误数据会导致决策失误、交易异常甚至资损。
- 用户体验一致性：同一用户在不同页面或不同时间看到的数据不一致，会降低信任度。
- 系统可靠性要求：缓存不一致可能引发缓存雪崩、缓存穿透等连锁故障。
- 数据合规与审计：金融、电商等场景要求数据可追溯、可对账，不一致数据会破坏审计链路。
⚠️ 常见误区：很多团队认为“缓存最终一致就够了”，但在秒杀、库存、支付等强一致性场景中，最终一致可能导致超卖、重复扣款等严重事故。缓存一致性策略必须根据业务场景分级设计。
1.3 常见缓存不一致场景
在实际生产环境中，缓存不一致通常由以下典型场景引发：
| 场景 | 触发条件 | 不一致表现 | 影响等级 |
|---|---|---|---|
| 先更新数据库，后更新缓存 | 更新数据库成功，更新缓存失败 | 缓存中仍是旧数据 | 高 |
| 先删除缓存，后更新数据库 | 删除缓存后，其他线程读取并设置旧缓存 | 缓存中写入旧数据 | 高 |
| 并发读写竞争 | 多个线程同时读写同一数据 | 缓存与数据库数据不一致 | 中高 |
| 缓存过期时间设置不当 | 过期时间过长或过短 | 数据更新后缓存未及时刷新 | 中 |
| 主从同步延迟 | Redis 主从复制延迟 | 不同节点读取到不同数据 | 中 |
| 分布式事务失败 | 跨服务缓存更新未回滚 | 部分缓存更新，部分未更新 | 高 |
💡 实践建议：在开始设计缓存一致性方案前，建议先梳理业务场景对一致性的敏感度。对于库存、余额等强一致场景，优先考虑“先更新数据库，再删除缓存”模式，并配合延迟双删或消息队列补偿；对于读多写少、允许短暂不一致的场景，可以接受较长的缓存过期时间。