缓存雪崩是指大量缓存键同时失效或redis服务整体不可用，导致请求集中穿透至数据库引发崩溃；核心防御包括随机化ttl、多级缓存、redis cluster部署、客户端容错及业务降级。
单纯增加 Redis 副本数不能避免雪崩；必须配合集群拓扑、客户端行为和业务层策略，否则副本越多，雪崩时打向数据库的流量越猛。
Redis 副本 ≠ 高可用缓存
很多人以为在 StatefulSet 里把 replicas: 6 就算部署了“高可用 Redis”，但实际只是多个独立实例——没启用 cluster-enabled yes，没做 slot 分片，没配置故障转移，它们之间互不感知。这种“多副本单点”结构，一旦主节点挂掉，所有请求仍会瞬间穿透到 DB。
真正防雪崩的前提是：Redis 层自身不整体失联。这意味着：
- 必须用
Redis Cluster模式（非哨兵或主从），至少 3 主 3 从共 6 节点 - 每个主节点负责部分 hash slot，故障时仅影响局部 key，而非全量穿透
- 客户端必须使用支持 cluster 的驱动（如
redis-py-cluster或JedisCluster），否则会路由失败或 fallback 到单点
StatefulSet 必须配对 Headless Service + Pod 反亲和
即使你写了 6 个副本，Kubernetes 默认调度可能把它们全塞进同一台 Node。节点宕机 → 所有 Redis 实例离线 → 全量雪崩。
解决方法是在 StatefulSet 的 spec.template.spec.affinity 中硬性声明反亲和：
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values: ["redis-cluster"]
topologyKey: "kubernetes.io/hostname"
注意两点：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
topologyKey: "kubernetes.io/hostname"表示按节点分散，不是按 zone 或 region（后者对小集群不实用） - 必须确保集群节点数 ≥ 副本数，否则
required会导致 Pod 卡在Pending
集群初始化后必须禁用 full-coverage
默认情况下，Redis Cluster 在某个分片不可用时（比如一个主+从全挂），会将整个集群置为 fail 状态，拒绝所有读写 —— 这反而放大雪崩风险。
必须在 redis.conf 中显式设置：
cluster-require-full-coverage no
这样即使 1/6 的 slot 不可用，其余 5/6 仍可正常服务。配合客户端重试（max-attempts: 3）和降级逻辑，才能真正实现“局部故障、全局可用”。
最容易被忽略的是客户端和业务层
集群健康 ≠ 缓存可用。你看到 CLUSTER INFO 显示 cluster_state:ok，不代表业务能稳定读写：
- 客户端没设
max-redirections或timeout，一次 slot 迁移未完成就卡死 - 所有 key 的 TTL 写死为
3600，没加随机偏移（new Random().nextInt(1800)），导致整点集体过期 - 没配本地缓存兜底（Caffeine/Guava），Cluster 故障时直接穿透 DB
- 没开降级开关（如通过 Apollo/Nacos 控制
cache.enabled），只能等 DB 被压垮
这些点不在 Kubernetes YAML 里，也不在 Redis 配置中，但决定了雪崩到底来不来。
