先删缓存，再更新数据库（适合读多写少场景）

• 步骤：删除缓存中对应 key → 更新数据库 → （可选）短暂延迟后异步重建缓存（避免缓存空窗期过长）。
• 优势：操作简单，避免脏写（缓存不会残留旧数据）。
• 注意：需处理 “缓存删除后、数据库更新前” 的读请求（可能读到旧数据），可通过设置缓存短期过期时间兜底。

先更新数据库，再删缓存（Write-Through 变种，适合写操作频率不高场景）

• 步骤：更新数据库 → 删除缓存中对应 key → 后续读请求触发缓存重建。

• 优势：避免 “删缓存失败导致的旧数据残留”（若数据库更新成功但删缓存失败，可通过重试机制补删）。

• 注意：需确保删缓存的重试机制（如消息队列重试），防止因网络问题导致删缓存失败。缓存更新策略（适用于强一致性要求）

• 双写模式：更新数据库后，同步更新缓存（需保证原子性，可通过事务或分布式锁实现）。

  • 问题：若缓存更新失败，会导致缓存与数据库不一致，需配合重试机制。读写锁：读操作加共享锁，写操作加排他锁，确保写操作期间缓存不会被脏读覆盖。

最终一致性方案（高并发场景）

• 异步更新：通过消息队列（如 RabbitMQ、Kafka）发送更新通知，消费者异步更新缓存，失败则重试。

• 版本号控制：为缓存数据添加版本号，更新时校验版本，避免旧数据覆盖新数据（如缓存版本＜数据库版本则更新）。

兜底机制（防止极端情况）

1. 缓存过期时间：为所有缓存 key 设置合理的过期时间（如 5-10 分钟），即使同步失败，过期后也会自动重建，保证最终一致。

2. 缓存预热与校验：定期全量 / 增量校验缓存与数据库数据，不一致则触发更新（适合核心数据）。

3. 分布式锁：在并发更新场景，通过分布式锁（如 Redis 的 SET NX）确保同一资源的更新操作串行执行，避免冲突。

场景化选择建议

转载自CSDN-专业IT技术社区

原文链接：https://blog.csdn.net/2302_78354192/article/details/157728211