在千万级用户系统中怎样利用Redis与本地缓存防止雪崩？-Redis-PHP中文网

本地缓存不能设为redis过期时间整数倍，因redis实际失效受随机化、预热等影响是动态的，而本地缓存若固定设为300秒（redis仅60秒），将导致4分钟确定性脏读；必须按redis返回ttl动态计算本地ttl（如×0.3），且上限≤30秒。

在千万级用户系统中怎样利用redis与本地缓存防止雪崩？

反例很典型：localTTL=300s、redisTTL=60s，结果是 Redis 早失效了，本地缓存还坚挺 4 分钟——用户看到的全是过期数据。这不是“多一层保险”，而是制造了一层**确定性脏读窗口**。

根本矛盾在于：本地缓存的生命周期必须与 Redis 缓存的**实际有效窗口**对齐，而非配置值。真实有效窗口受随机化过期、主动刷新、后台预热等策略影响，是动态的。

本地缓存 + Redis 组合后，容易出现「本地缓存未命中 → 批量打到 Redis → Redis 热点 Key 击穿」。这不是缓存雪崩，但效果类似：单个 Redis key 成为瓶颈，CPU 跑满，连接池打爆。

关键不是加锁，而是**分流+降级**：

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

本地缓存命中率低于 70% 时，自动启用「请求合并」：相同 key 的并发请求在本地排队，只放行 1 个去查 Redis，其余等待返回后共享结果
对高频读场景（如用户基础信息），本地缓存启用「软过期」：过期前 5 秒开始异步刷新，不阻塞读请求；刷新失败则沿用旧值（带告警）
Redis 层对这类 key 单独配置 maxmemory-policy=volatile-lru，避免被大 key 挤出内存；同时禁用 scan 类全量命令（会拖垮节点）

千万级系统里，选型不是看 API 多简洁，而是看它怎么扛住 GC 压力和并发抖动。

Caffeine 是当前事实标准：基于 Window TinyLfu 算法，缓存命中率比 Guava 高 15%~20%，且内存占用更稳；特别适合长尾热点分布（比如 80% 请求集中在 5% 的 key 上）
Guava Cache 在低并发、key 数量稳定时够用，但高并发下 asMap().get() 可能触发全表遍历，GC pause 明显；不推荐用于实时性要求
无论选哪个，必须关闭 weakKeys/softValues：千万级系统里，GC 回收不可控，会导致缓存批量失效，反而诱发雪崩

这是最隐蔽的坑：Redis 挂了，本地缓存还在返旧数据，前端不断重试，后端不断重建本地缓存 → 流量翻倍打向数据库。

必须做「熔断感知」：

本地缓存模块监听 Redis 连接状态（如 Lettuce 的 ConnectionWatchdog），连续 3 次 ping 失败后，自动切换为「只读模式」：拒绝所有写入，且对未命中 key 直接返回 null（不查 DB）
每个本地缓存 entry 增加 lastRedisHitTime 字段，每次成功从 Redis 读取后更新；若该字段距今 > 60 秒，该 entry 视为「陈旧」，不参与命中逻辑
禁止在本地缓存 miss 时 fallback 到数据库 —— 这条规则必须硬编码进 cache loader，而不是靠上层业务判断

真正难的不是加缓存，而是让每一层都清楚自己「什么时候该沉默」。本地缓存一旦失去 Redis 的上下文，就必须退化为只读快照，而不是试图扮演救世主。