Redis Cluster 多 key 命令为什么要求 hash tag

在 Redis Cluster 里，MSET、SINTER、事务和 Lua 脚本都可能同时涉及多个 key。它们要求相关 key 位于同一个 hash slot，原因是 Redis Cluster 的每个 slot 由一个主节点负责，单条命令不会替你跨节点合并数据。hash tag 就是为这个约束准备的键名规则：让多个 key 共享一段花括号内的标识，从而得到同一个 slot。

先把多 key 命令放回 Redis Cluster 的槽位模型

Redis Cluster 把 key 空间划分为 16384 个 hash slot，每个主节点负责其中一部分。普通 key 的计算可以理解为 CRC16(key) mod 16384。单 key 命令只需要找到一个负责节点；而 MSET、集合交集、事务或 Lua 脚本如果同时访问多个 key，就必须让这些 key 归属于同一个 slot，服务器才能在一个节点上完成这条命令。

例如下面两组键的业务含义相近，但第一组未必同槽：

# 普通键名：整个字符串分别参与槽位计算，可能落到不同节点
redis-cli -c MSET user:1001:profile "..." user:1001:orders "..."

# 同一 hash tag：只让 1001 参与槽位计算
redis-cli -c MSET user:{1001}:profile "..." user:{1001}:orders "..."

第一条如果跨槽，会收到类似 CROSSSLOT Keys in request don't hash to the same slot。这不是客户端连接错了，而是当前键模型无法满足这条多 key 命令的路由条件。

用 hash tag 让相关键稳定落到同一槽

合法 hash tag 需要同时满足三个条件：key 中出现 {；右侧存在 }；两者之间至少有一个字符。Redis Cluster 会取第一个左花括号和它右侧第一个右花括号之间的非空内容计算 slot，其他前缀和后缀只是命名信息。

因此，同一用户的资料、购物车和未读计数可以这样命名：

# 共享 {1001}，便于针对一个用户执行多 key 命令
user:{1001}:profile
user:{1001}:cart
user:{1001}:unread

# tag 不同，不能因为前缀相同就假定它们同槽
user:{1001}:profile
user:{1002}:cart

这个设计适合“同一实体的一组 key 必须一起读写”的边界，不适合把所有业务都写成同一个 tag。比如全站都使用 {global}，虽然跨槽错误少了，却会把大量访问压到一个 slot 对应的节点上，削弱集群的横向扩展。

用 CLUSTER KEYSLOT 检查键名是否真的同槽

不要凭肉眼判断冒号前缀。可以让 Redis 直接返回 key 的 slot，尤其要检查花括号为空、嵌套花括号和 tag 拼写不一致等边界。

# 同时检查普通键与共享 tag 的槽位
redis-cli -c CLUSTER KEYSLOT user:1001:profile
redis-cli -c CLUSTER KEYSLOT user:{1001}:profile
redis-cli -c CLUSTER KEYSLOT order:{1001}:latest

# 空 tag 不生效；这类 key 按完整字符串计算
redis-cli -c CLUSTER KEYSLOT user:{}:profile

# 生产排查时把返回的整数逐行记录，便于和客户端键名生成逻辑比对

只要两个合法 tag 的内容完全相同，前后缀可以不同，返回的 slot 就应相同。检查时还要确认客户端没有在 key 前后偷偷拼接租户、环境或版本标识，导致原本约定的 tag 内容发生变化。

在一致性与热点之间做键空间取舍

hash tag 的代价是牺牲一部分分布均匀性，换取一个业务聚合键的同槽能力。可以先列出真正需要同一条命令处理的 key，再决定 tag 的粒度：

如果业务确实要跨 slot 聚合，优先考虑拆成多个单槽操作、在应用层汇总，或重新设计数据模型，而不是无限扩大 tag 的共享范围。Redis Cluster 的扩容和迁移也不会消除同槽约束。

把 CROSSSLOT、MOVED 和 TRYAGAIN 分开处理

CROSSSLOT 通常说明请求中的 key 本来就不在同一个 slot，应修正键名或拆分命令；盲目重试不会改变槽位。MOVED 表示客户端的 slot 到节点映射需要更新，支持集群模式的客户端一般会自动处理。TRYAGAIN 则可能出现在相关 slot 正在迁移的窗口，适合按客户端策略短暂重试。

发布前可以把下面三项加入检查清单：一是收集所有多 key 命令、事务和脚本的 key；二是对每组候选 key 执行 CLUSTER KEYSLOT；三是统计共享 tag 对应节点的请求量和内存，确认同槽设计没有制造单点热点。

常见问题

为什么 key 前缀一样仍然会 CROSSSLOT？

槽位计算默认使用完整 key，user:1001 和 user:1002 的前缀相同并不代表结果相同。需要显式共享合法的 {tag}。

一个 key 可以有多个花括号吗？

可以，但 Redis 使用第一个左花括号与其右侧第一个右花括号之间的非空片段。复杂嵌套写法可读性差，建议只放一个简短、稳定的 tag，并用 CLUSTER KEYSLOT 验证。

hash tag 是否应该所有 key 都使用同一个值？

不应该。它只服务于必须同槽的协作边界；全局复用会集中流量和内存，削弱 Redis Cluster 的分片收益。