本地缓存不能替代Redis，但可缓解雪崩冲击；其适用场景是Redis超时或短暂不可用时兜底返回旧值，而非强一致或跨实例共享；必须配置maximumSize和expireAfterWrite，禁用refreshAfterWrite，redisTemplate超时需设短（如100ms），本地TTL须短于Redis（如30秒vs5分钟）。
本地缓存不能替代Redis，但能缓解雪崩冲击
本地缓存（如Caffeine、Guava Cache）对单进程有效，不解决集群一致性问题，也不感知Redis是否宕机。它真正起作用的场景是：Redis响应超时、网络抖动、或短暂不可用时，用本地已有的旧值兜住一部分请求，避免全部穿透到DB。一旦把它当成“强一致缓存”或“跨实例共享缓存”来用，就踩进坑了。
Caffeine + RedisTemplate 的串行 fallback 逻辑怎么写
关键不在加依赖，而在控制调用顺序和失败边界。下面这个 get 方法是实际线上可用的最小闭环：
public String get(String key) {
// 1. 先查本地，命中直接返回
String local = caffeineCache.getIfPresent(key);
if (local != null) return local;
// 2. 查 Redis，必须设短超时（比如 100ms）
try {
String remote = redisTemplate.opsForValue().get(key);
if (remote != null) {
// 写回本地时注意：过期时间要比 Redis 短（如 Redis 5min → 本地 30s）
caffeineCache.put(key, remote);
}
return remote;
} catch (Exception e) {
// 3. Redis异常时，再捞一次本地——可能刚被其他线程写入
return caffeineCache.getIfPresent(key);
}
}
-
caffeineCache必须配置maximumSize和expireAfterWrite，否则内存泄漏风险极高 - 禁用
refreshAfterWrite：它会异步加载，掩盖超时问题，且无法控制 fallback 行为 -
redisTemplate的timeout要显式设小（setConnectionTimeout/setSoTimeout），否则本地缓存形同虚设
本地缓存过期时间为什么必须比Redis短
这是最容易被忽略的设计点。如果本地缓存比Redis活得久，就会出现“Redis已更新，本地还在返回脏数据”的情况，且无法通过常规手段感知和刷新。典型配置是：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- Redis TTL：300 秒（5 分钟）
- 本地 TTL：30 秒（
expireAfterWrite(30, TimeUnit.SECONDS)） - 这样即使 Redis 因主从延迟、AOF重放等原因返回旧值，本地最多 stale 30 秒，且能快速被新值覆盖
多实例部署下本地缓存的一致性风险
每个应用实例都有自己的本地缓存副本，它们之间完全独立。这意味着：
- 一个实例更新了本地缓存，其他实例完全不知道
- 如果业务要求“任意实例读到的数据必须一致”，本地缓存就不该启用
- 若允许几秒 stale（比如商品价格展示），可配合
invalidate事件广播（如通过 Redis Pub/Sub 主动清空各实例本地 key），但这增加了复杂度和延迟
真正的难点从来不是“怎么加一层缓存”，而是明确接受它带来的 stale 窗口，并把 fallback、超时、降级逻辑落到每一处 get 调用里。
