在应对高并发读请求时，单靠Redis一层缓存容易在网络开销和连接竞争上遇到瓶颈。把热点数据进一步前置到应用进程内部，再结合Redis做共享层，就形成了多级缓存架构。这种结构能显著降低远程调用比例，但也带来了层级间数据同步的新问题。
多级缓存的层级设计与路由原理
典型的多级缓存分为三级：第一级是进程内缓存，例如使用Caffeine或Ehcache，数据存放在JVM堆中，访问延迟通常在微秒级；第二级是Redis这样的集中式缓存，所有节点共享，解决进程间数据不一致问题；第三级是数据库或远程服务，作为最终数据源。请求到来时先查本地缓存，未命中再查Redis，仍未命中才回源，这种漏斗模型能拦截掉绝大部分流量。
为了让某条数据尽量落在同一台Redis节点，避免全量广播，工程上常用一致性哈希做分片路由。客户端根据key的哈希值映射到哈希环上的虚拟节点，再定位到物理Redis实例。当集群扩容时，只有少量key需要迁移，本地缓存也可依据相同路由规则判断哪些条目可能失效。下面是一段简化的一致性哈希工具示例：
import java.util.SortedMap;
import java.util.TreeMap;
public class ConsistentHash {
private SortedMap<Integer, String> ring = new TreeMap<>();
private int virtualNodes = 100;
public void addNode(String node) {
for (int i = 0; i < virtualNodes; i++) {
int hash = (node + i).hashCode();
ring.put(hash, node);
}
}
public String getNode(String key) {
int hash = key.hashCode();
SortedMap<Integer, String> tail = ring.tailMap(hash);
if (tail.isEmpty()) {
return ring.get(ring.firstKey());
}
return tail.get(tail.firstKey());
}
}
上述代码通过虚拟节点降低数据倾斜，实际项目中可结合Redisson的分布式特性做进一步封装。需要注意的是，本地缓存不会因为Redis节点变化自动清空，所以必须设计主动失效机制，否则旧节点上的本地数据可能长期滞留。
数据一致性与失效广播方案
多级缓存最大的挑战是层级间一致性。当数据库记录更新，如果只删Redis而本地缓存不知道，就会读到脏数据。常见做法是利用Redis的发布订阅能力，在更新操作完成后发送一个失效主题消息，各应用节点订阅该主题，收到消息后删除对应的本地条目。这样秒级内全集群本地缓存都能感知变化。
另一种方案是给本地缓存设置较短的过期时间，用时间换一致性，但会造成少量请求穿透到Redis。相比之下，广播失效更精准。以下代码展示了SpringBoot中通过RedisTemplate发送与接收失效消息：
@Autowired
private RedisTemplate<String, String> redisTemplate;
public void updateData(String id, String value) {
// 更新数据库省略
redisTemplate.convertAndSend("cache_invalidate", id);
}
@EventListener
public void onMessage(Message message) {
String id = message.getBody().toString();
caffeineCache.invalidate(id);
}
使用发布订阅时要注意网络抖动可能导致消息丢失，因此对核心数据建议辅以定时全量校验或版本号比对。可以在Redis中存一个全局版本号，本地缓存携带版本，读取时发现版本落后则强制刷新。这种双重保障在交易类系统中尤为重要。
缓存击穿与雪崩的防护实践
多级架构下，本地缓存能天然挡住大部分击穿流量，但Redis层依然可能因某个热点key失效瞬间涌入大量回源请求。此时可在本地使用互斥锁或RateLimiter限制回源并发，只有拿到锁的线程去查Redis和数据库，其余线程等待结果。
对于雪崩，核心思路是错开过期时间。在写入本地和Redis时，基础TTL上加上随机偏移，例如本地缓存30秒加减5秒，Redis设60秒加减10秒。这样不会出现同一时刻大批量key集体失效。下面给出Caffeine配合随机TTL的配置片段：
Caffeine<String, String> caffeine = Caffeine.newBuilder()
.expireAfterWrite(30 + new Random().nextInt(10), TimeUnit.SECONDS)
.maximumSize(10000);
Cache<String, String> cache = caffeine.build();
同时，在Redis客户端侧可开启熔断，当数据库压力大时直接返回本地旧值并异步刷新，保证用户侧可用性。经过以上三层防护，系统即使在极端流量下也能将错误率控制在可接受范围，并维持较低的响应延迟。