Redis Cluster key slot用 CRC16 解释跨槽排查的实现方法

Redis Cluster 的跨槽问题，先看 key slot，不要先怀疑网络。一个 key 的基础槽位由 CRC16(key) mod 16384 得到；多键命令要求涉及的 key 落在同一个 slot，否则就可能收到 CROSSSLOT Keys in request don't hash to the same slot。排查时用 CLUSTER KEYSLOT 逐个计算，再决定是否用 hash tag 调整键名。

Redis Cluster key slot 的计算链路和 CRC16 边界

Redis Cluster 把 key 空间拆成 16384 个槽，每个 master 负责其中一部分。普通 key 直接参与 CRC16；如果 key 中存在左花括号，右侧有非空内容且随后能找到右花括号，Redis 只对第一段有效花括号中的内容计算。这就是为什么 user:1000:profile 与 user:1000:orders 不会因为都含有 user:1000 就自动同槽。

先把计算链路记成四步：确定参与计算的字节串，执行 Redis 规定的 CRC16 XMODEM，计算结果对 16384 取模，得到 0 到 16383 的槽号。CRC16 的参数不是任意库的默认值；实现排查工具时，不能只写一个名字相同但多项参数不同的 CRC16。

# 先分别计算普通 key 与带 hash tag 的 key，确认真正参与路由的对象
redis-cli -c -h 127.0.0.1 -p 6379 CLUSTER KEYSLOT user:1000:profile
redis-cli -c -h 127.0.0.1 -p 6379 CLUSTER KEYSLOT {user:1000}:profile
redis-cli -c -h 127.0.0.1 -p 6379 CLUSTER KEYSLOT {user:1000}:orders

用 CLUSTER KEYSLOT 把跨槽错误缩小到具体键

面对 MGET、事务或 Lua 脚本的跨槽报错，先列出命令中每一个 key，逐个执行 CLUSTER KEYSLOT。不要把客户端收到的 -MOVED 和 CROSSSLOT 混为一谈：前者通常表示请求节点需要把某个槽路由到别处，后者说明一次多键操作的槽约束没有满足。

实际操作中还要确认命令的 key 参数位置。比如 Lua 脚本通过 KEYS 传入的两个键，即便业务上属于同一个用户，只要槽号不同，集群也不会替你跨节点合并执行。此时记录“键名、槽号、命令”三列，通常比反复重试更快定位。

跨槽排查的实现方法：先按业务键使用 Hash Tag

修复的重点不是给 key 随便加前缀，而是把需要原子协作的业务实体放进同一个稳定 tag。例如用户资料与用户订单需要一次读取，可以设计为 {user:1000}:profile 和 {user:1000}:orders，两者都只对 user:1000 计算槽位。命名方案要在写入前确定，否则新旧 key 会分散在不同节点。

# 只有两个 slot 相同，才把多键命令作为同槽方案继续测试
redis-cli -c -h 127.0.0.1 -p 6379 CLUSTER KEYSLOT {user:1000}:profile
redis-cli -c -h 127.0.0.1 -p 6379 CLUSTER KEYSLOT {user:1000}:orders
# 同槽后再验证多键读取；示例不代表本文已连接生产集群
redis-cli -c -h 127.0.0.1 -p 6379 MGET {user:1000}:profile {user:1000}:orders

Hash tag 也有代价：如果大量请求都把同一个高频标识放入花括号，就可能形成热点槽。跨槽排查的结论应同时回答两个问题：这次操作是否必须原子完成，以及把哪些 key 放到同槽后会不会牺牲负载均衡。

上线前的检查清单和边界

• 普通 key 要按完整 key 计算；有效 hash tag 才使用花括号内的非空内容。
• 检查第一个有效花括号对，foo{{bar}}zap 这类写法不要凭直觉猜结果。
• 把 CROSSSLOT、-MOVED、-ASK 分开记录；迁移期间的重定向不等于槽设计错误。
• 客户端必须启用 Cluster 模式并处理重定向；服务端不会充当跨节点代理替你拼接多键结果。

这套方法只解决“哪些 key 落在哪个 slot、为什么一次操作跨槽”的定位问题。它不能替代数据迁移、热点治理或客户端路由表更新；如果槽号相同但仍报错，再转向命令参数、脚本声明和客户端实现排查。

常见问题

Redis Cluster 为什么不是按 key 前缀分片？

前缀只是完整 key 的一部分，默认参与整串 CRC16。只有显式使用有效 hash tag，才会把花括号内容作为路由依据。

花括号加上以后一定能避免热点吗？

不能。它能让相关 key 同槽，却也可能把高频用户、租户或房间集中到一个槽，必须结合访问量评估。

收到 MOVED 时要修改 key 名吗？

通常不用。MOVED 是节点路由提示，Cluster 客户端应刷新槽位映射；只有确认多键操作的 slot 不一致时，才讨论 hash tag 或拆分命令。

如何快速确认两个 key 是否同槽？

对两个完整 key 分别执行 CLUSTER KEYSLOT，返回相同数字才具备同槽前提；不要只比较它们的字符串前缀。