Redis Cluster hash tag 怎样让相关键落在同一槽位

Redis Cluster 要让关联键落到同一个槽位，直接用原生的 hash tag 特性就可以实现，操作方法很简单：给这些相关键的键名里加一段被英文大括号包裹的共同标识，集群计算槽位时只会拿大括号里的内容做CRC16哈希运算，所有带相同大括号内容的键就会自动落到同一个槽位，原本跨槽无法使用的多键操作、事务等功能都可以正常执行。

只要多个关联键的键名中被英文半角大括号包裹的子串内容完全一致，它们就会被分配到Redis Cluster的同一个哈希槽。

Redis Cluster 中，相关键能否放到同一槽位，关键不在于键名前缀是否相同，而在于键名中是否使用了正确的 hash tag。把实体标识放进一对非空花括号，例如 user:{42}:profile 和 user:{42}:orders，Redis 只对 42 计算槽位，因此两个键具备执行多键命令、事务或脚本的同槽位条件。

• 先看现象：CROSSSLOT 通常表示请求中的键不在同一槽位。
• 再看设计：把稳定的业务实体标识放在 {} 内，而不是只复用普通前缀。
• 最后看代价：tag 太粗会制造热点，tag 太细又不能满足多键操作。

先确认 CROSSSLOT 到底说明了什么

Redis Cluster 将键空间拆成 16384 个 hash slot。普通键按 CRC16(key) mod 16384 计算，相关键只要落在不同槽位，集群就不能把一次多键请求当成单槽位操作处理。比如直接写 user:42:profile 与 user:42:orders，前缀相同并不能保证同槽位；如果把它们交给需要单槽位的命令，可能看到 CROSSSLOT Keys in request don't hash to the same slot。

这里要把三类现象分开：CROSSSLOT 是请求内的键槽位不一致；MOVED 是客户端访问了当前不负责该槽位的节点；ASK 常与槽位迁移过程有关。只有第一类需要优先检查 hash tag 设计。

用花括号把同一业务实体绑定在一起

推荐把会被同一次请求共同读取或修改的实体 ID 放在花括号内，业务语义放在外部。例如订单详情、订单状态和订单锁可以设计成：

# 同一个订单 ID 放在花括号内，保证相关键使用同一个 hash tag
redis-cli -c -h redis-node-1 -p 6379 MGET \
  'order:{9001}:detail' \
  'order:{9001}:status'

# 用不同实体 ID 隔离不同订单，避免所有订单共用一个槽位
redis-cli -c -h redis-node-1 -p 6379 MSET \
  'order:{9001}:status' 'paid' \
  'order:{9001}:version' '7'

这种写法的重点是“同一实体共置”，不是“所有相关数据共置”。例如 order:{9001}:detail 与 order:{9001}:status 可以共槽位，但不要把 tag 固定成 {order}，否则所有订单都会集中到同一个槽位，削弱集群横向分布能力。

如果业务操作跨越多个实体，例如一次批量结算要同时改动订单 9001 和 9002，就不能仅靠一个订单级 tag 解决。此时要么拆分操作，要么重新设计聚合边界；不要把所有实体都塞进一个全局 tag。

按 Redis 的实际规则理解花括号

Redis 并不是看到任意花括号就只取里面的文字。只有同时满足“存在 {、右侧存在 }、两者之间至少有一个字符”，才会把首个有效区间作为 hash tag。几个容易误判的例子如下：

# 下面是规则示意，不是本机运行输出
{user1000}.following  与  {user1000}.followers  -> 都按 user1000 计算
foo{}{bar}                              -> 首个花括号区间为空，按完整键名计算
foo{{bar}}zap                           -> 按首个花括号到右侧首个花括号之间的内容计算
foo{bar}{zap}                           -> 使用首个有效区间 bar

因此，tag 需要稳定且可读：不要把可变排序字段、随机数或过长的 JSON 放进去，也不要在同一套 key 规范里混用空 tag、嵌套 tag 和多个业务实体。key 规范应在客户端封装层统一生成，避免一个实体出现两种花括号写法。

用 CLUSTER KEYSLOT 检查设计是否成立

设计好 key 后，先用 Redis 自己的算法检查槽位，而不是根据字符串前缀猜测。CLUSTER KEYSLOT 返回指定 key 的槽位，下面的命令应分别比较成对的相关键：

# 在集群节点上查看两个订单键是否同槽位
redis-cli -c -h redis-node-1 -p 6379 CLUSTER KEYSLOT 'order:{9001}:detail'
redis-cli -c -h redis-node-1 -p 6379 CLUSTER KEYSLOT 'order:{9001}:status'

# 对比不同订单，确认 tag 没有被错误地固定成全局常量
redis-cli -c -h redis-node-1 -p 6379 CLUSTER KEYSLOT 'order:{9001}:status'
redis-cli -c -h redis-node-1 -p 6379 CLUSTER KEYSLOT 'order:{9002}:status'

前两条返回相同整数，说明这两个键满足同槽位设计；后两条通常应返回不同整数，但具体数值取决于实体 ID 的 CRC16 结果。这里的检查只证明槽位计算关系，不代表数据一定存在，也不代表客户端已经正确处理集群重定向。

如果仍然出现 CROSSSLOT，按这个顺序排查：客户端最终发送的 key 是否和预期一致；花括号是否为空或被转义；多键命令是否混入了另一个实体；连接是否真的启用了集群模式；脚本或事务声明的 key 是否全部来自同一 tag。排除这些后，再看客户端的路由与槽位缓存。

上线前的反向验证清单

修复后不要只测试一个 GET。至少用真实命令边界检查一次：需要同槽位的 MGET、MSET、事务、pipeline 或 Lua 脚本，确认它们使用的所有 key 都带有同一个实体 tag；同时抽样多个实体，确认 tag 不会把全部请求集中到单一槽位。

1. 同一实体的相关键：花括号内容完全一致且非空。
2. 不同实体的键：花括号内容按实体变化，不使用全局固定值。
3. 命令边界：多键命令、事务和脚本的全部 key 都经过统一 key builder。
4. 异常区分：CROSSSLOT 查 key 设计，MOVED 查集群客户端路由。
5. 容量边界：观察实体分布，避免为了省事制造单槽位热点。

常见问题

键名前缀一样，为什么仍然 CROSSSLOT？

普通前缀不会参与“共槽位保证”。只有符合规则的非空 {...} 区间才会让相关键使用同一个 hash tag。

能不能把所有 key 都写成 {app}？

不建议。这样虽然容易满足同槽位条件，却会把大量读写集中到一个槽位，失去集群分片的收益。应按真正的聚合实体选择 tag。

hash tag 能解决 MOVED 吗？

不能直接解决。hash tag 解决的是请求内多个 key 的槽位一致性；MOVED 需要集群客户端更新槽位到节点的路由信息。