先删缓存，再更新数据库（适合读多写少场景）
- 步骤：删除缓存中对应 key → 更新数据库 → （可选）短暂延迟后异步重建缓存（避免缓存空窗期过长）。
- 优势：操作简单，避免脏写（缓存不会残留旧数据）。
- 注意：需处理 "缓存删除后、数据库更新前" 的读请求（可能读到旧数据），可通过设置缓存短期过期时间兜底。
先更新数据库，再删缓存（Write-Through 变种，适合写操作频率不高场景）
-
步骤：更新数据库 → 删除缓存中对应 key → 后续读请求触发缓存重建。
-
优势：避免 "删缓存失败导致的旧数据残留"（若数据库更新成功但删缓存失败，可通过重试机制补删）。
-
注意：需确保删缓存的重试机制（如消息队列重试），防止因网络问题导致删缓存失败。缓存更新策略（适用于强一致性要求）
-
双写模式：更新数据库后，同步更新缓存（需保证原子性，可通过事务或分布式锁实现）。
- 问题：若缓存更新失败，会导致缓存与数据库不一致，需配合重试机制。读写锁：读操作加共享锁，写操作加排他锁，确保写操作期间缓存不会被脏读覆盖。
最终一致性 方案（高并发场景）
-
异步更新：通过消息队列（如 RabbitMQ、Kafka）发送更新通知，消费者异步更新缓存，失败则重试。
-
版本号控制：为缓存数据添加版本号，更新时校验版本，避免旧数据覆盖新数据（如缓存版本＜数据库版本则更新）。
兜底机制（防止极端情况）
-
缓存过期时间：为所有缓存 key 设置合理的过期时间（如 5-10 分钟），即使同步失败，过期后也会自动重建，保证最终一致。
-
缓存预热与校验：定期全量 / 增量校验缓存与数据库数据，不一致则触发更新（适合核心数据）。
-
分布式锁：在并发更新场景，通过分布式锁（如 Redis 的 SET NX）确保同一资源的更新操作串行执行，避免冲突。
场景化选择建议
|------------|-----------------------|--------------|
| 场景 | 推荐方案 | 核心目标 |
| 读多写少、非核心数据 | 先删缓存，再更新数据库 | 减少写操作对读性能的影响 |
| 写操作频繁、强一致性 | 先更新数据库，再删缓存 + 重试机制 | 降低缓存脏数据概率 |
| 高并发、最终一致性 | 异步更新 + 版本号控制 + 过期时间兜底 | 平衡性能与一致性 |