Slot分配不均会引发雪崩风险，因热点key或bigkey集中于同一节点导致CPU、内存、网络过载，触发被动淘汰并加剧请求穿透，造成“可用但不可靠”的局部雪崩。
为什么Slot分配不均会直接引发雪崩风险
Redis Cluster 的 16384 个 Slot 是数据路由的唯一依据，但 Slot 分配本身不感知 key 的访问频率或体积。一旦大量热点 key 或 bigkey 被哈希到同一组 Slot，而这些 Slot 又被集中分配给某个节点，该节点就会成为单点瓶颈——CPU、内存、网络带宽瞬间拉满，响应延迟飙升，CLUSTER INFO 显示 ok，但客户端已开始收到 MOVED 重定向失败或 ASK 超时；更危险的是，该节点若因过载触发 maxmemory-policy 被动淘汰，会批量踢掉正在被高频访问的 key，导致请求穿透加剧，形成“局部雪崩”。这不是集群不可用，而是“可用但不可靠”。
如何检查当前Slot分布是否倾斜
别依赖肉眼数节点，用命令直击真实分配：
- 运行
redis-cli -h {node_ip} -p {port} cluster slots，输出每行形如0 5460 127.0.0.1:7000 127.0.0.1:7003，其中前两个数字是 Slot 范围，第三个是主节点，第四个是从节点 - 统计每个主节点负责的 Slot 数量：对所有行提取第三列 IP:PORT，按出现次数计数（可用
awk '{print $3}' | sort | uniq -c | sort -nr） - 重点看最大值与平均值的比值：16384 / 主节点数 = 理论均值；若某节点 Slot 数 > 均值 × 1.3，即存在明显倾斜
- 补充验证：在该节点上执行
info memory | grep used_memory_human和info stats | grep instantaneous_ops_per_sec，确认内存和 QPS 是否同步偏高
迁移Slot时必须加 --threshold 1
用 redis-cli --cluster rebalance 自动均衡看似省事，但默认行为会一次性搬走大块 Slot（如上千个），这会触发两重风险：一是迁移期间目标节点内存陡增，可能触发 oom-kill；二是大量 key 在新节点重建后，TTL 时间戳未变，却因 slot 集中迁入而集体进入失效窗口。必须强制细粒度迁移：
- 使用
--threshold 1参数：它让 rebalance 每次只移动 1 个 Slot，确保迁移节奏可控 - 配合
--weight手动指定权重：例如--weight 127.0.0.1:7000=0.8降低高负载节点接收新 Slot 的概率 - 迁移全程监控
cluster_state和cluster_slots_pfail，发现pfail状态立即暂停 - 禁止在业务高峰执行，且每次迁移后至少观察 15 分钟
used_memory_peak_human和慢日志
Hash Tag滥用是隐形倾斜加速器
业务代码里写 user:{1001}:profile 和 user:{1001}:orders 看似合理，但如果所有用户 ID 都落在同一段连续区间（比如刚上线的运营活动用户 ID 全是 1000~1099），那所有 {1000} 到 {1099} 的 Hash Tag 就会映射到极少数 Slot，再叠加 Slot 分配不均，等于双重放大倾斜。更隐蔽的是全局 Tag：{global}:counter 这种写法会让所有计数器挤在一个节点。
- 禁用任何形式的静态、泛化 Hash Tag，如
{all}、{common}、{hot} - 动态 Tag 必须带散列因子：例如
user:{1001%8}:profile，把用户 ID 对 8 取模，强制分散到 8 个不同 Slot 组 - 对已存在的滥用 Tag key，用
SCAN+MIGRATE批量重写，不要用KEYS（阻塞主线程） - CI/CD 流水线中加入 Redis Key 格式校验规则，正则匹配
\{[a-zA-Z0-9_]+\}并告警非业务语义 Tag
真正难处理的不是 Slot 数量偏差，而是 Slot 下 key 的访问热度与体积不可见——你永远不知道哪个 {1001} 正在承载秒杀商品库存。所以 Slot 均衡只是起点，必须和随机 TTL、本地缓存兜底、热点 key 多副本策略一起落地，否则一次 redis-cli --cluster rebalance --threshold 1 执行完，你只是把雪崩从“今天”推迟到了“下次批量过期”。
