缓存雪崩时Redis不自动冗余，需应用层打散过期时间（如EX 3600+随机偏移）并结合本地缓存构成二级冗余，主从/集群均无法解决冷数据缺失问题。
缓存雪崩发生时，Redis 本身不自动做数据冗余
Redis 是单节点（或主从）存储系统，它不会因为“缓存雪崩”就自动复制、预热或 fallback 到其他副本。所谓“通过 Redis 实现数据冗余防雪崩”，本质是应用层配合 Redis 构建的多级/多源策略，不是 Redis 自身功能。
常见错误现象：大量 key 同时过期 → 请求穿透到 DB → DB 负载飙升 → 接口超时堆积。这时候光靠 Redis 主从同步没用——从节点一样没数据，主节点也空。
- Redis 主从只解决高可用（故障转移），不解决冷数据缺失问题
- 集群模式（Redis Cluster）也不提供跨 slot 的数据冗余备份
-
EXPIRE时间集中设置是典型诱因，必须打散
给 key 设置随机过期时间是最简单有效的冗余前置手段
这不是“冗余存储”，而是“冗余存活时间”，让失效点分散，避免瞬时压垮下游。这是成本最低、见效最快的防线。
使用场景：所有批量写入缓存的业务，比如首页推荐列表、用户配置聚合、商品类目树。
- 不要写
SET key value EX 3600，改用SET key value EX 3600+ 随机偏移，例如EX 3600 + random(0, 600) - 在应用代码中生成偏移，而非依赖 Redis 命令（Redis 没有内置随机 TTL）
- Spring Data Redis 示例：
redisTemplate.opsForValue().set(key, value, Duration.ofSeconds(3600 + ThreadLocalRandom.current().nextInt(600)))
本地缓存（Caffeine/Guava）+ Redis 组成二级缓存才是真冗余
当 Redis 全挂或大面积 miss 时，本地缓存能抗住一部分读请求，避免全部打到 DB。这不是替代 Redis，而是补它的单点脆弱性。
性能影响：本地缓存命中延迟在
- 本地缓存设较短
expireAfterWrite（如 60s），避免脏数据滞留太久 - 更新 DB 后，主动
invalidate本地缓存 +DELRedis key，不要只删一个 - 不要用本地缓存存大对象（如 1MB JSON），容易 OOM；适合小而热的数据，如用户权限、开关配置
- 若用 Caffeine，建议开启
recordStats()，监控hitRate和evictionCount，判断是否真起作用
Redis 多实例分片 + fallback 到备用集群需手动路由控制
严格来说这不是“Redis 冗余”，而是架构层冗余。两个独立 Redis 集群（比如 cluster-a 和 cluster-b），同一份数据写双写，读的时候优先读主集群，失败后降级读备集群。
容易踩的坑：双写一致性难保，尤其网络分区时容易脑裂。
- 必须用最终一致性模型，接受短暂不一致，不要强求实时同步
- 写操作建议走
RedisPipeline或异步任务发往备用集群，避免主链路阻塞 - 读逻辑里封装
tryReadFromPrimary() catch { tryReadFromBackup() }，不能靠客户端自动 failover - 监控
backup_read_ratio指标，如果长期 >5%，说明主集群已不稳定，得告警介入
maximumSize 设太大或没设），反而会掩盖雪崩信号，让问题更难定位。 
