【Java面试】你是怎么控制缓存的更新？

🔄 一、数据实时同步失效（强一致性）

原理：数据库变更后立即失效或更新缓存，保证数据强一致。
实现方式：

1. Cache Aside（旁路缓存）：

   • 读流程：读缓存 → 未命中则读库 → 回填缓存。
   • 写流程：更新数据库 → 删除缓存（非更新）。
   • 关键优化：
     • 延迟双删：更新DB后删除缓存，延迟500ms再删一次，防止并发读导致的脏数据。
     • 加锁防击穿：缓存未命中时，用分布式锁（如Redis SETNX）控制单线程读库回填。
   • 适用场景：金融交易、库存扣减等强一致性场景。

2. Read/Write Through（读写穿透）：

   • 应用只操作缓存，由缓存服务同步更新数据库（如Ehcache + DB集成）。
   • 优点：业务无侵入；缺点：写延迟高，依赖缓存服务可靠性。

---

⏱️ 二、数据准实时更新（最终一致性）

原理：数据库变更后异步更新缓存，延迟通常在毫秒~秒级。
实现方式：

1. 消息队列解耦：

   • 更新数据库 → 发MQ（如Kafka） → 消费者异步更新缓存。
   • 关键设计：
     • 消息顺序性：同一数据的更新需保证顺序消费（如Kafka分区键用数据ID）。
     • 幂等处理：消费端校验版本号或唯一ID，防重复更新。

2. Binlog监听：

   • 工具监听数据库Binlog（如Canal） → 解析变更事件 → 更新缓存。
   • 优点：与业务解耦，适合多服务协作场景。

适用场景：电商商品详情页、社交动态等可容忍短暂不一致的场景。

---

⏰ 三、任务调度更新（最终一致性）

原理：定时任务批量同步数据库与缓存，延迟分钟~小时级。
实现方式：

1. 增量同步：

   • 任务扫描DB变更记录（如update_time字段），仅同步增量数据。
   • 优化：分页查询 + 时间窗口滚动，避免全表扫描。

2. 全量同步：

   • 定期全量刷缓存（如每日凌晨），兜底数据一致性。
   • 风险：大数据量时可能引发数据库负载陡增，需分批次执行。

适用场景：BI报表、排行榜等低频变更、高计算耗时的数据。

---

🔧 四、增量 vs 全量更新策略

策略	适用场景	技术要点
增量更新	数据变更频繁，需高效同步	基于Binlog/更新时间戳，仅同步变更部分。
全量更新	数据量小或变更极少	定时全量扫描，配合缓存预热机制。

---

💡 五、选型建议与避坑指南

1. 一致性要求：

   • 强一致：实时同步 + 延迟双删（如支付系统）。
   • 最终一致：消息队列/Binlog异步（如内容展示页）。

2. 性能与风险平衡：

   • 频繁写场景避免直接更新缓存，优先删除（防无效写入）。
   • 热点数据用逻辑过期：缓存永不过期，后台异步更新数据。

3. 兜底设计：

   • 所有策略需叠加 TTL过期，防逻辑漏洞导致长期脏数据。

---

总结：

• 实时同步：强一致首选，但需应对并发问题（延迟双删 + 锁）。
• 准实时更新：平衡性能与一致性，依赖消息顺序与幂等。
• 任务调度：最终一致兜底，适合离线计算场景。
  最终建议：90%场景用 Cache Aside + 异步补偿（如MQ），配合TTL过期，兼顾开发效率与稳定性。