Redis 中如何保证缓存与数据库的数据一致性？

Redis 缓存与数据库数据一致性解决方案

【核心定义】

保证缓存与数据库数据一致性，本质是通过设计合理的数据更新策略与失效机制，在分布式环境下协调缓存层与持久层的数据状态，确保业务读取到的始终是正确数据。

【关键要点】

先更新数据库，后删除缓存（Cache-Aside + Delete）
- 结论：这是业界最主流的最终一致性方案
- 原理：业务更新时先完成数据库写入，成功后立即删除（而非更新）Redis缓存，后续读取时触发缓存重建
- 优势：避免复杂的双写并发问题，实现简单可靠
设置合理的过期时间（Expiration）
- 结论：通过TTL为缓存数据增加“自愈”能力
- 原理：即使出现不一致，过期后自动失效，重新从数据库加载正确数据
- 关键值：根据业务容忍度设置30秒-30分钟不等，平衡一致性与性能
延迟双删策略（Delayed Double Delete）
- 结论：针对极端并发场景的增强方案
- 原理：更新数据库 → 删除缓存 → 延迟数百毫秒 → 再次删除缓存
- 解决场景：处理“先删缓存后更新DB”期间读请求导致的旧数据回填

【深度推导/细节】

核心矛盾：并发场景下的数据竞争

时间线分析（先更新DB后删缓存）：
Step 1: 线程A更新数据库（value=新值）
Step 2: 线程B读取缓存（命中旧值）← 此时A尚未删除缓存
Step 3: 线程A删除缓存
Step 4: 线程B将旧值写入缓存 ← 问题发生！

结果：缓存中残留旧数据，直到下一次更新或过期

解决方案推演：

方案一：同步双写（不推荐）

// 问题：并发写时顺序无法保证，且事务失败回滚复杂
updateDB(data);
updateCache(data); // 可能失败导致不一致

方案二：消息队列保证最终一致性

// 可靠但复杂
1. 更新数据库，写入binlog
2. Canal监听binlog变化
3. 发送MQ消息
4. 消费者删除/更新缓存
// 优点：完全解耦，可重试
// 缺点：架构复杂，延迟较高

方案三：版本号/时间戳控制

// 每次更新递增版本号
{
  "value": "data",
  "version": 3,
  "update_time": "2024-01-01 12:00:00"
}
// 读取时校验版本，旧版本不更新缓存

【关联/对比】

方案	一致性强度	性能影响	复杂度	适用场景
先更新DB，后删缓存	最终一致性	低	低	大多数业务场景
同步双写	强一致性	高	中	金融、交易核心数据
消息队列异步	最终一致性	中	高	高并发写场景
设置过期时间	弱一致性	无	低	可容忍短期不一致

与本地缓存对比：

Redis作为分布式缓存：需要处理多节点一致性问题
本地缓存（如Caffeine）：只需保证单机DB与缓存一致，但集群间可能不一致

【线程安全与版本差异】

多线程场景保护：

缓存重建加锁：防止缓存击穿时大量请求穿透到DB

// 使用Redis分布式锁或本地锁
String lockKey = "product:lock:" + id;
if (redis.setnx(lockKey, "1", 3)) {
    try {
        // 查询数据库并重建缓存
    } finally {
        redis.del(lockKey);
    }
}

读写分离下的特殊处理：
- 主从延迟期间可能读到旧数据
- 方案：关键数据强制读主库，或延迟删除缓存（等主从同步完成）

Redis版本特性利用：

Redis 6.0+：支持多线程IO，可更快处理删除操作
Redis 4.0+：支持UNLINK异步删除，避免大Key阻塞
Redis Module：可使用RediSearch等模块实现更复杂的一致性逻辑

『面试官追问』

删除缓存失败怎么办？
- 实现删除重试机制（最多3次）
- 记录失败日志，告警人工干预
- 最终依赖缓存过期时间兜底
为什么是删除缓存而不是更新缓存？
- 避免并发写导致的顺序问题
- 减少计算浪费（可能后续无人读取）
- 防止缓存与DB的不必要耦合
如何保证绝对强一致性？
- 使用分布式事务（如Seata）
- 业务层加全局锁（性能极差）
- 直接读数据库，放弃缓存（仅限核心交易）
热点Key频繁更新导致缓存击穿？
- 使用互斥锁重建缓存
- 缓存空值（Null Object Pattern）
- 本地缓存+较短过期时间
先删缓存还是先更新数据库？
- 先删缓存：可能造成长时间不一致（DB更新慢）
- 先更新DB：不一致窗口期较短（毫秒级）
- 推荐先更新DB，不一致时间更短

【直击痛点：关键设计考量】

1. 不一致容忍时间

支付状态：要求秒级一致，需强一致性方案
商品库存：可容忍3-5秒不一致，最终一致性足够
文章阅读数：可容忍分钟级不一致，设置过期时间即可

2. 删除操作的性能考量

大Key删除：使用UNLINK替代DEL，避免阻塞
批量删除：使用Pipeline减少网络往返
删除时机：非高峰时段执行批量清理

3. 监控与告警

监控指标:
  - 缓存命中率 < 90% 告警
  - 缓存删除失败率 > 1% 告警
  - DB查询QPS突增（可能缓存大面积失效）

【最佳实践总结】

基础方案：先更新数据库 → 立即删除缓存 + 设置合理TTL
增强方案：增加延迟双删 + 删除重试机制
高级方案：Binlog监听 + 消息队列异步处理
兜底方案：缓存过期自动失效 + 人工干预通道

选择原则：根据业务对一致性的要求程度，选择最简单有效的方案，避免过度设计。90%的场景使用“先更新DB后删缓存”即可满足需求。

# Redis 中如何保证缓存与数据库的数据一致性？