本地缓存不能设为Redis过期时间整数倍，因Redis实际失效受随机化、预热等影响是动态的，而本地缓存若固定设为300秒（Redis仅60秒），将导致4分钟确定性脏读；必须按Redis返回TTL动态计算本地TTL（如×0.3），且上限≤30秒。
为什么本地缓存不能简单设成 Redis 过期时间的整数倍
反例很典型：localTTL=300s、redisTTL=60s，结果是 Redis 早失效了，本地缓存还坚挺 4 分钟——用户看到的全是过期数据。这不是“多一层保险”，而是制造了一层**确定性脏读窗口**。
根本矛盾在于：本地缓存的生命周期必须与 Redis 缓存的**实际有效窗口**对齐，而非配置值。真实有效窗口受随机化过期、主动刷新、后台预热等策略影响，是动态的。
- 本地缓存应只作为「瞬时兜底」，不是「长期代理」；建议
localTTL≤redisTTL的 1/3，且上限不超过 30 秒 - 禁止用固定时间戳计算本地过期，必须从 Redis 返回的
TTL值推导（例如：取redisTTL返回值 × 0.3，向下取整） - 若业务允许弱一致性，本地缓存可完全不设 TTL，靠「写穿透」或「失效广播」同步清理（但需配套消息通道）
双层缓存怎么避免本地缓存击穿 Redis 热点 Key
本地缓存 + Redis 组合后，容易出现「本地缓存未命中 → 批量打到 Redis → Redis 热点 Key 击穿」。这不是缓存雪崩，但效果类似：单个 Redis key 成为瓶颈，CPU 跑满，连接池打爆。
关键不是加锁，而是**分流+降级**：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 本地缓存命中率低于 70% 时，自动启用「请求合并」：相同 key 的并发请求在本地排队，只放行 1 个去查 Redis，其余等待返回后共享结果
- 对高频读场景（如用户基础信息），本地缓存启用「软过期」：过期前 5 秒开始异步刷新，不阻塞读请求；刷新失败则沿用旧值（带告警）
- Redis 层对这类 key 单独配置
maxmemory-policy=volatile-lru，避免被大 key 挤出内存；同时禁用scan类全量命令（会拖垮节点）
本地缓存该用 Caffeine 还是 Guava Cache
千万级系统里，选型不是看 API 多简洁，而是看它怎么扛住 GC 压力和并发抖动。
-
Caffeine是当前事实标准：基于 Window TinyLfu 算法，缓存命中率比 Guava 高 15%~20%，且内存占用更稳；特别适合长尾热点分布（比如 80% 请求集中在 5% 的 key 上） -
Guava Cache在低并发、key 数量稳定时够用，但高并发下asMap().get()可能触发全表遍历，GC pause 明显；不推荐用于实时性要求 - 无论选哪个，必须关闭
weakKeys/softValues：千万级系统里，GC 回收不可控，会导致缓存批量失效，反而诱发雪崩
Redis 宕机时本地缓存如何不变成放大器
这是最隐蔽的坑：Redis 挂了，本地缓存还在返旧数据，前端不断重试，后端不断重建本地缓存 → 流量翻倍打向数据库。
必须做「熔断感知」：
- 本地缓存模块监听 Redis 连接状态（如 Lettuce 的
ConnectionWatchdog），连续 3 次ping失败后，自动切换为「只读模式」：拒绝所有写入，且对未命中 key 直接返回 null（不查 DB） - 每个本地缓存 entry 增加
lastRedisHitTime字段，每次成功从 Redis 读取后更新；若该字段距今 > 60 秒，该 entry 视为「陈旧」，不参与命中逻辑 - 禁止在本地缓存 miss 时 fallback 到数据库 —— 这条规则必须硬编码进 cache loader，而不是靠上层业务判断
真正难的不是加缓存，而是让每一层都清楚自己「什么时候该沉默」。本地缓存一旦失去 Redis 的上下文，就必须退化为只读快照，而不是试图扮演救世主。
