cluster keyslot 命令直接返回 key 对应的槽号（0–16383），仅支持单个 key，自动提取哈希标签 {} 内容参与 crc16 计算，不返回节点地址；查节点需配合 cluster slots 解析槽段映射。
CLUSTER KEYSLOT 命令直接算出槽位
Redis 不会直接告诉你 key 在哪个节点，但会告诉你它属于哪个哈希槽（0–16383）。这是定位的第一步，必须用 CLUSTER KEYSLOT 手动触发计算，而不是靠客户端自动路由来“猜”。
常见错误是误以为 GET 或 EXISTS 返回的重定向信息（MOVED）能稳定复用——其实它只在当前连接上下文有效，且不暴露目标节点地址，仅用于客户端自动跳转。
- 连接任意集群节点，带
-c参数启用集群模式：redis-cli -c -h 192.168.1.10 -p 6379 - 执行：
CLUSTER KEYSLOT myuser:1001→ 返回整数，比如(integer) 6789 - 注意：key 中含花括号时只取
{...}内部内容参与 CRC16 计算，例如user:{1001}:profile和user:{1001}:orders一定落在同一槽
CLUSTER SLOTS 查看槽到节点的映射关系
CLUSTER SLOTS 返回的是整个集群的槽段分配快照，格式为数组嵌套：每个元素是 [起始槽, 结束槽, [主节点IP, 端口, 节点ID], [从节点信息...]]。你得自己遍历匹配刚才算出的槽号。
容易踩的坑是把 CLUSTER NODES 当成替代方案——它只列节点状态和负责槽范围的摘要，不保证字段顺序或完整性；而 CLUSTER SLOTS 是唯一权威、结构化、可编程解析的映射源。
- 执行：
CLUSTER SLOTS - 找包含
6789的那一段，比如：1) 1) (integer) 5461 2) (integer) 10922 3) 1) "192.168.1.103" 2) (integer) 6379 ... - 确认该段起止槽覆盖你的槽号，主节点 IP+端口就是目标地址
Python 脚本里别硬编码 CRC16 实现
虽然 CRC16 是公开算法，但不同语言/库对输入预处理（如是否加前缀、字节序）可能有差异。官方客户端（如 redis-py-cluster）内部已封装一致逻辑，直接调用 cluster("keyslot", key) 更可靠。
自己实现时若用 binascii.crc32，必须注意：Redis 实际用的是 CRC16-CCITT（非 CRC32），且对 key 字符串做 raw bytes 处理，binascii.crc32 会错。
- 正确做法：用
crc16包（如pip install crc16）并传入bytes：crc16.crc16xmodem(b"mykey") % 16384 - 更省事：用
r.execute_command("CLUSTER KEYSLOT", "mykey")，让服务端算，避免本地实现偏差 - 别在循环里反复调
CLUSTER SLOTS—— 它返回全量数据，建议缓存一次结果再查槽
redis-trib.rb 已废弃，别依赖它
redis-trib.rb 在 Redis 5.0+ 中已被移除，文档里还提它纯属历史遗留。现在所有运维操作都由 redis-cli --cluster 子命令接管，但它不提供单 key 查询功能。
试图运行 redis-trib.rb info mykey 会失败，除非你还在用 4.x 版本且没升级集群管理工具。线上环境应统一使用 redis-cli -c + CLUSTER KEYSLOT + CLUSTER SLOTS 组合。
真正容易被忽略的是：集群拓扑变更（如 add-node / reshard）后，CLUSTER SLOTS 结果会变，但客户端不会自动刷新缓存。如果脚本长期运行，需定期重拉该命令结果，否则槽映射会过期。
