Redis 5.0集群如何查看槽位分配_通过CLUSTER SLOTS精准排查数据分布-Redis-PHP中文网

cluster slots 直接列出每个连续槽段的起止编号、负责主节点及所有从节点，是唯一实时完整展示槽与节点映射的原生命令；槽段须连续无重叠无遗漏，否则集群状态为fail。

redis 5.0集群如何查看槽位分配_通过cluster slots精准排查数据分布

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></master-id> 或 CLUSTER ADDSLOTS —— 该节点在 CLUSTER SLOTS 中完全不出现，属于「幽灵节点」。

只要 CLUSTER SLOTS 输出里有一段槽没主节点，或者某段重复出现两次，集群就不可写。这个细节，比日志里的 warning 更值得盯紧。