用 cluster slots 校验槽位分布需检查三方面：是否覆盖0-16383全范围、槽段间无重叠或空隙、各主节点负责槽数量差异≤5%；cluster info 的 cluster_slots_assigned 不验证连续性与唯一性；cluster nodes 中 MIGRATING/IMPORTING 状态标识迁移中槽。
用 cluster slots 查槽位分布是否均匀
这个命令返回的是嵌套数组结构，每项代表一个连续槽段（如 [0, 5460, ["192.168.1.100", "6379", "abc123"], ["192.168.1.103", "6379", "jkl012"]]），直接肉眼扫容易漏掉空隙或重叠。生产环境必须写脚本校验三件事：
所有槽段加起来是否覆盖 0-16383；
任意两个槽段不能有交集；
每个主节点负责的槽数量差异不能超过 5%（比如 3 主节点，理想是各 ~5461，若某节点只有 3000，说明迁移不均或卡住）。
别依赖 cluster info 里 cluster_slots_assigned: 16384 就认为没问题——它只统计“已分配”，不校验“是否连续”或“是否重复”。
用 cluster nodes 抓取 MIGRATING/IMPORTING 状态
迁移中节点会在 cluster nodes 输出里带标志位，例如：abc123 ... master - 0 0 1 connected 0-5460 MIGRATING [1000 -> def456]def456 ... master - 0 0 2 connected 5461-10922 IMPORTING [1000 <br>关键点：<br>只允许当前正在迁移的 slot 出现在至多一个 <code>MIGRATING 和一个 IMPORTING 条目中；
如果某个 slot 同时出现在两个源节点的 MIGRATING 行里，说明配置错乱；
如果 MIGRATING 行存在但对应 IMPORTING 行缺失，目标节点可能网络不通或拒绝连接。
用 INFO 监控 migrating_keys 是否持续下降
在源节点执行 INFO，搜 migrating_keys 字段，它表示“该节点当前正在迁移、尚未完成的 key 数量”。这个值必须单调递减，且每分钟至少降 100。如果停滞超过 3 分钟：
检查目标节点 used_memory_peak_human 是否接近上限（内存打满会导致 MIGRATE 命令失败静默）；
确认源节点与目标节点之间 redis-cli -h dst -p port PING 能通，且无防火墙拦截集群总线端口（默认 port+10000）；
避免在迁移期间触发 BGREWRITEAOF 或 SAVE，它们会抢 CPU 导致 MIGRATE 超时被中断。
为什么 cluster info 的 cluster_state: ok 不代表迁移安全
cluster_state: ok 只表示 Gossip 心跳正常、无节点被标记为 fail，它完全不感知 slot 迁移进度。你可能看到这个字段一直是 ok，但实际有 200 个 slot 卡在 MIGRATING 状态长达 15 分钟——客户端访问这些 slot 时会频繁收到 ASK 重定向，延迟毛刺明显，而监控大盘却毫无告警。真正要盯的是 migrating_slots 和 importing_slots 这两个 INFO 字段，以及每 10 秒轮询一次 cluster nodes | grep -E "(MIGRATING|IMPORTING)" 的输出行数变化。
