如何保证缓存数据的一致性：数据库和缓存数据一致性，本地缓存和Redis缓存怎么保证数据一致性

多级缓存，本地缓存和Redis缓存怎么保证数据一致性？

设置本地缓存短时间内失效

设置本地缓存短时间内失效，短的存活周期，保证了数据的时效性比较高，当数据失效之后，再次访问数据就会拉取新的数据了，这样能尽可能的保证数据的一致性。

它的特点是：代码实现简单，不需要写多余的代码；缺点是，效果不是很明显，不适合高并发的系统。

本地缓存自动更新功能

使用本地缓存框架的自动更新功能，例如 Caffeine 中的 refresh 功能来自动刷新缓存，这样就可以设置很短的时间来更新最新的数据，从而也能尽可能的保证数据的一致性。

更新策略	refreshAfterWrite	expireAfterWrite
‌触发时机‌	访问时延迟刷新	到期立即失效
‌数据可用性‌	始终有数据（旧或新）	可能短暂无数据
‌性能影响‌	异步无阻塞	同步加载可能阻塞

refreshAfterWrite执行过过程

写入数据A(time=0s) 
→ 5秒后(time=5s)数据仍在缓存中 
→ 第6秒访问时触发异步刷新 
→ 立即返回旧数据A 
→ 后台加载新数据A' 
→ 加载完成后替换缓存中的A

refreshAfterWrite的底层实现原理‌是采用‌惰性触发+异步加载‌的机制。具体实现可分为先步骤：

---

一、时间标记与条件检查

1. ‌写入时间记录‌
   每个缓存项会记录最后一次写入时间戳，作为刷新时间计算的基准。

2. ‌访问时阈值判断‌
   当访问缓存时，比较当前时间与写入时间+refresh间隔：

   • 若未达到阈值：直接返回现有值
   • 若达到阈值：触发异步刷新流程

---

二、异步刷新控制

1. ‌非阻塞式加载‌
   通过后台线程池（如ForkJoinPool）异步执行刷新任务，避免阻塞用户请求线程。

2. ‌单线程防抖‌
   对同一key的并发刷新请求会合并，确保只有一个加载操作执行（通过细粒度锁或CAS控制）。

3. ‌新旧数据隔离（采用类似ConcurrentHashMap的分段锁设计）‌

   • 刷新过程中继续返回旧数据
   • 新数据加载完成后原子性替换

通过配置中心协调和同步

通过微服务中的配置中心（例如 Nacos）来协调，因为所有服务器都会连接到配置中心，所以当数据修改之后，可以修改配置中心的配置，然后配置中心再把配置变更的事件推送给各个服务，各个服务感知到配置中心的配置发生更改之后，再更新自己的本地缓存，这样就实现了本地缓存的数据一致性。

具体的流程描述

1. ‌Redis缓存发生变更‌（比如：某个业务修改了Redis里的数据）
   → ‌但Nacos本身不会监控Redis的变化‌，需要‌业务代码主动通知Nacos‌。

2. ‌业务代码感知到Redis变更后，主动更新Nacos配置‌
   → 比如调用Nacos的API，更新一个特定的配置项（例如：cache_version=2）。

3. ‌Nacos将配置变更推送给所有监听的服务‌
   → 各个微服务通过‌长轮询（Long Polling）‌或‌WebSocket‌实时接收Nacos的配置变更通知。

4. ‌各服务收到Nacos的通知后，主动更新本地缓存‌
   → 比如：

   • 直接清空本地缓存（下次访问时重新加载）
   • 或者调用Redis获取最新数据，更新本地缓存

高频问题

‌1. Nacos配置监听机制‌

• ‌核心问题‌：如何通过Nacos监听配置变更？
  • ‌回答要点‌：
    • 客户端通过addListener订阅配置（Data ID + Group）
    • 采用‌长轮询（Long Polling）‌机制，默认30秒超时，配置变更后立即推送
    • 监听器Listener接口实现receiveConfigInfo方法处理变更逻辑

---

‌2. 数据一致性保障‌

• ‌核心问题‌：如何保证Redis与本地缓存的数据一致性？
  • ‌回答要点‌：
    • ‌版本号设计‌：通过Nacos配置中的版本号（如时间戳）标记变更
    • ‌最终一致性‌：依赖Nacos的AP模式（Distro协议）实现异步同步
    • ‌本地缓存更新策略‌：清空缓存或主动拉取最新数据

---

‌3. 多级缓存协同‌

• ‌核心问题‌：Redis、Nacos、本地缓存如何协同工作？
  • ‌回答要点‌：
    1. Redis变更 → 业务代码主动更新Nacos版本号
    2. Nacos推送变更 → 服务更新本地缓存（如Caffeine）
    3. ‌降级策略‌：本地缓存未命中时回源Redis

---

‌4. 性能与可靠性‌

• ‌核心问题‌：如何避免频繁更新导致的性能问题？
  • ‌回答要点‌：
    • ‌批量更新‌：合并短时间内的多次变更，减少推送频率
    • ‌本地缓存过期时间‌：设置合理的TTL（如30分钟）
    • ‌容错机制‌：Nacos集群故障时降级为读取本地缓存

---

‌5. 对比其他方案‌

• ‌核心问题‌：与直接监听Redis的Pub/Sub有何区别？
  • ‌回答要点‌：
    • ‌Nacos优势‌：解耦业务逻辑，支持配置版本管理
    • ‌Pub/Sub劣势‌：需维护Redis连接，无历史版本回溯能力

分布式缓存与数据库如何保证一致性

四大同步策略

策略顺序	优点	缺点	适用场景
先更新缓存再更新数据库	缓存命中率高	第二步失败导致缓存脏数据	不推荐使用
先更新数据库再更新缓存	相对安全	第二步失败导致缓存旧数据	低并发场景
先删除缓存再更新数据库	操作简单	缓存击穿风险，数据不一致	不推荐使用
‌先更新数据库再删除缓存（推荐）‌	影响最小	删除失败导致旧数据	大多数场景

延时双删

针对上面这种情况，我们有一种延时双删的方法

1）删除缓存

2）更新数据库

3）休眠 500ms（这个时间，依据读取数据的耗时而定）

4）再次删除缓存
这时候唯一存在的一个问题就是，在（更新据库 + 休眠 500 ms） 这个时间窗口中，依旧能读取到旧值，而这个短暂时间控制的好的话，是可以接受的。

基于消息队列的异步同步（如Canal+MQ）‌

1. ‌工作原理‌
   • 通过监听数据库的binlog（如MySQL的ROW模式），使用Canal捕获增删改事件并推送至消息队列（Kafka/RocketMQ）‌。
   • 消费者服务订阅消息，根据事件类型删除或更新缓存，实现最终一致性‌