本地缓存+分布式缓存多级结构如何协同工作？如何保持一致性？

一、多级缓存协同工作逻辑

多级缓存（本地缓存+分布式缓存）通过"层层拦截请求"降低分布式缓存压力，核心流程如下：

• 1.优先查本地缓存：应用进程优先读取本地缓存（如Java的Caffeine、Guava Cache），命中则直接返回，响应最快（微秒级）。

• 2.本地未命中查分布式缓存：若本地缓存无数据，再请求分布式缓存（如Redis、Memcached），命中后返回数据，并同步更新本地缓存（避免下次重复查分布式）。

• 3.分布式未命中查数据库：若分布式缓存也未命中，最终查询数据库，将结果同步写入分布式缓存和本地缓存，完成"三级存储"闭环。

二、一致性保持方案

多级缓存的一致性核心是"避免本地缓存与分布式缓存/数据库数据不一致"，需针对性处理两类场景：

1. 数据更新时的一致性保障

先更数据库，再删缓存（而非更新）：

①.业务系统先更新数据库数据； ②.删除分布式缓存中对应key（避免直接更新缓存导致的并发覆盖问题）； ③.可选：通过"过期时间"让本地缓存自动失效（或发送通知主动清理集群内其他节点的本地缓存）。

为何不直接更新缓存？：若并发场景下，A更新数据库后未更缓存，B先查缓存（旧值）再更新数据库，会导致缓存被B的旧值覆盖，数据不一致。

2. 本地缓存的"失效补偿"

TTL过期策略

• 设置合理过期时间：本地缓存必须配置过期时间（如10-30秒），即使未主动清理，也能通过过期自动对齐分布式缓存数据，避免长期不一致。

主动失效策略

• 分布式通知清理：若业务对一致性要求极高，可通过MQ或广播机制，当分布式缓存key被删除时，通知所有应用节点清理本地缓存中对应的key。

版本号控制

• 每次数据更新时递增版本号，版本缓存时带上版本号，读取时校验版本号。可以使用版本号的方式保证数据的一致性

3. 极端场景兜底：缓存降级

• 若分布式缓存故障，可临时让本地缓存直接查数据库更新（降级策略），避免服务雪崩；待分布式缓存恢复后，再重新同步数据。

4. 缓存层级策略

本地缓存	分布式缓存	数据库
热点数据，配置信息，用户会话等	共享数据，大容量数据，需要持久化数据	完整的业务数据，需要事务保证的数据

5.实施策略对比

策略	一致性	性能影响	实现复杂度	应用场景
主动失效	较强	中等	高	强一致性要求
TTL过期	最终一致性	低	低	高性能要求
版本号	强一致性	高	高	强一致性要求
组合策略	可调整	可调整	高	复杂业务场景