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 必须由运维主动触发；没人动，加再多节点，新节点也是空跑。雪崩防不住，从来不是算法问题，而是控制权有没有落到人手里。
