CLUSTER SLOTS 直接列出每个连续槽段的起止编号、负责主节点及所有从节点，是唯一实时完整展示槽与节点映射的原生命令；槽段须连续无重叠无遗漏，否则集群状态为fail。
CLUSTER SLOTS 返回结果怎么看
CLUSTER SLOTS 是唯一能实时、完整展示槽位与节点映射关系的原生命令。它不返回哈希值或统计摘要，而是直接列出每个槽段（slot range）由哪个节点负责、哪些节点是其从节点。
执行后典型输出类似：
127.0.0.1:7000> cluster slots
1) 1) (integer) 0
2) (integer) 5460
3) 1) "192.168.1.101"
2) (integer) 7000
3) "a1b2c3d4e5f6..." // 主节点 ID
4) 1) "192.168.1.102"
2) (integer) 7001
3) "f7g8h9i0j1k2..." // 从节点 ID
关键点：
- 第一层列表每一项代表一个「连续槽段」，不是单个槽；
- 每段的起始/结束槽号是包含的（如
0到5460共 5461 个槽）； - 第三个元素是主节点信息（IP、端口、ID），第四个起是该主节点的所有从节点（可能为空）；
- 槽段之间不能重叠、不能遗漏，否则集群状态为
fail。
为什么不能只看 CLUSTER NODES 或 redis-cli --cluster check
CLUSTER NODES 只显示节点角色和连接状态，不体现槽归属；redis-cli --cluster check 会汇总槽总数并报错（如 FAIL: Slot 12345 is not covered），但不告诉你「谁该管它」或「谁多占了」。
真实排查场景中，你常需要确认：
- 某个业务 key 实际落在哪个槽？用
crc16(key) % 16384算出槽号后，得靠CLUSTER SLOTS定位到具体节点； - 扩容后新节点没分到槽？查输出里有没有以它为主节点的段；
- 某节点宕机后槽是否被自动迁移？对比宕机前后的
CLUSTER SLOTS输出，看对应槽段的主节点 ID 是否变更。
如何快速定位 key 对应的节点（不依赖客户端）
在任意集群节点上，用两步手动验证：
第一步：算槽号。例如 key 是 "user:1001"，可用 Python 快速计算：
python3 -c "import binascii; print(binascii.crc_hqx(b'user:1001', 0) % 16384)"
第二步：查槽段。假设结果是 8237，执行 CLUSTER SLOTS，逐段比对起止范围，找到包含 8237 的那一项，第三元素的 IP 和端口就是目标节点。
注意：
- 不要用
redis-cli -c直接 get —— 它内部跳转是黑盒，无法确认是否真连到了负责该槽的节点； - 某些旧版客户端（如 Jedis 2.x）对槽迁移响应不及时，手动验证可绕过客户端缓存干扰；
- 如果
CLUSTER SLOTS中没有覆盖 8237 的段，集群已处于fail状态，所有写入都会失败。
常见误操作导致 CLUSTER SLOTS 异常
运维中最容易踩的坑不是命令不会用，而是「以为分配了，其实没生效」：
- 执行了
CLUSTER ADDSLOTS 1000 1001 1002，但没在**所有节点**上同步执行CLUSTER SETSLOT ... MIGRATING或IMPORTING—— 导致只有本节点认为自己管这些槽，其他节点不认； - 用
redis-cli --cluster reshard迁移中途 Ctrl+C，迁移未完成且未回滚，CLUSTER SLOTS显示源节点仍标有该槽段，但部分 key 已迁走，造成数据不一致； - 新增节点后只执行
CLUSTER MEET，忘了CLUSTER REPLICATE <master-id>或CLUSTER ADDSLOTS—— 该节点在CLUSTER SLOTS中完全不出现，属于「幽灵节点」。
只要 CLUSTER SLOTS 输出里有一段槽没主节点，或者某段重复出现两次，集群就不可写。这个细节，比日志里的 warning 更值得盯紧。
