Redis Cluster单节点故障不会导致全集群雪崩，因其16384个槽位分散在多个主节点，仅影响该节点负责的槽位；雪崩多由客户端未处理重定向、key扎堆同一槽或缺失从节点引发。
Redis Cluster 本身不会因单节点故障引发全集群雪崩——只要槽位（slot）分配完整、从节点配置到位，故障仅影响该节点负责的 1/3 或更小比例的数据，其余节点照常服务。真正导致“雪崩感”的，往往是客户端未正确处理 MOVED / ASK 重定向、或关键业务 key 全部落在同一 slot 范围内。
为什么单节点宕机通常不等于雪崩
Redis Cluster 的故障隔离能力来自其哈希槽设计：16384 个 slot 均匀分散在多个主节点上，每个主节点只承载一部分 slot（比如 3 主节点时平均约 5461 个）。当节点 A 宕机：
- 只有它负责的 slot 暂时不可写（若无从节点）或短暂只读（若有从节点且已升主）；
- 其他节点的 slot 完全不受影响，客户端发往它们的请求照常执行；
- 集群仍能响应大部分 key 的读写，只要客户端不硬编码连接到已下线节点。
容易引发连锁失败的三个实操坑
所谓“雪崩”，多是客户端或业务逻辑没适配集群行为所致：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
客户端直连固定 IP + 端口，且未启用集群模式：比如用
redis-cli -h 10.0.1.10 -p 6379连接某节点后执行所有命令，一旦该节点宕机，所有请求直接失败，不会自动跳转； -
大量 key 使用相同 hash-tag（如
{user:1001}:profile和{user:1001}:settings）：导致这些 key 全部落入同一 slot，再集中在一个主节点上——该节点成热点，也成单点； -
未配置从节点，或从节点未启用
cluster-enabled yes+replicaof <master-addr>：主节点宕机后无节点可接管，对应 slot 进入fail状态，集群整体cluster_state变为fail（只要有一个 slot 未被任何节点服务，集群就拒绝写操作）。
分片合理性检查与调整手段
判断当前分片是否健康，不能只看节点数，要验证 slot 分布和故障转移能力：
- 运行
redis-cli -c -h <any-node> -p <port> cluster slots，确认每个主节点都分配了非空 slot 区间，且总和覆盖 0–16383； - 用
redis-cli -c cluster nodes查看输出中每个主节点是否有slave标记的同行，并确认其状态为connected； - 对业务高频 key 手动计算 slot：
CRC16("your:key") % 16384（可用 Python 或在线工具），检查是否意外扎堆——若发现{order:20240904}*全落在 slot 1200，就得改用更散列的 tag 或加随机后缀； - 扩容时用
redis-cli --cluster reshard迁移 slot，**不要**直接修改nodes.conf或手动cluster addslots，否则可能造成 slot 冲突或集群状态不一致。
最关键的忽略点：客户端必须用 Smart Client
几乎所有官方推荐客户端（JedisCluster、Lettuce、redis-py-cluster）都实现了集群拓扑自动感知和重定向自动跟随。但很多人部署时仍沿用单机 client 配置，或在连接池里写死单个地址。结果就是：集群明明好着，客户端却因一次 MOVED 就抛异常、打满重试、压垮下游。真正的分片合理性，一半在服务端 slot 分配，另一半在客户端是否真的“懂”集群——这点比加多少节点都重要。
