redis cluster采用哈希槽而非取模或一致性哈希，因取模扩容导致全量key重路由而雪崩，一致性哈希仍存数据倾斜与故障连锁风险；哈希槽通过固定16384槽位、手动分配与原子迁移，实现扩容不丢命中、故障限域、负载可控。

简单加节点不能防雪崩，是因为底层分片机制没变——如果还在用 hash(key) % N 这种取模方式，扩容后所有 key 的归属全乱了，缓存命中率归零，后端瞬间被打穿。

为什么 hash(key) % N 扩容必然引发雪崩

这是最原始的分片逻辑，每个 key 直接按节点数取模决定去哪台机器。问题出在“N”是硬编码进路由规则里的：

• 原有 4 节点时，key1 → hash(key1) % 4 == 2 → 落在 node2
• 加到 5 节点后，同一 key 变成 hash(key1) % 5 == 0 → 路由到 node0，但 node0 根本没存过它
• 所有 key 都重算，99% 请求 miss，穿透到下游，流量尖峰直接压垮数据库

一致性哈希为什么只缓解、不根治雪崩

它把节点和 key 都映射到一个 0~2³²-1 的环上，新增节点只影响环上相邻区间，迁移量约 1/N。但真实场景中仍有硬伤：

Redis Skill - 高性能缓存管理

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

下载

• 节点哈希值分布随机，容易出现「大段空隙」或「密集扎堆」，导致部分节点负载翻倍
• 故障时，失效节点的数据全顺时针压给下一个节点，若该节点容量/性能不足，立刻被拖垮，形成连锁反应
• 虚拟节点能改善倾斜，但引入额外元数据开销和实现复杂度，Redis 官方没采用这套逻辑

Redis Cluster 用哈希槽真正规避雪崩的关键点

它不靠节点在环上的位置，而是把整个空间切成固定 16384 个 CLUSTER_SLOTS，再手动把槽分给节点。这带来三个不可替代的控制力：

• 槽迁移是原子的：增节点时，从各 master 上匀出一部分槽（比如各挪 1000 个）给新节点，不是“全量重哈希”，旧 key 仍能命中原槽位，服务不中断
• 故障影响被严格限定：nodeA 挂了，只影响它负责的那批槽（比如 slots 0-2000），其他 14000+ 槽照常响应；配合主从复制，这些槽可秒级切换
• 负载可人工干预：高性能节点配 slots 0-8191，低配节点只分 slots 12288-16383，避免“强弱混搭却平均分配”的陷阱

真正容易被忽略的是：哈希槽本身不自动平衡，cluster addslots 和 cluster setslot 必须由运维主动触发；没人动，加再多节点，新节点也是空跑。雪崩防不住，从来不是算法问题，而是控制权有没有落到人手里。