Redis Cluster 多 key 操作的哈希标签设计

Redis Cluster 多 key 操作的关键不是把所有 key 写成相似前缀，而是让一次命令中必须协同的 key 共享同一个有效 hash tag。Redis 会对标签内容计算槽位，因此 user:{1001}:profile 和 user:{1001}:quota 可以落到同一槽位；但把所有用户都写成 {users}，又会把本来可以分散的流量集中到一个槽位。

官方地址：https://redis.io/docs/latest/

本文只讨论 hash tag、槽位检查和热点风险，不展开客户端连接池、故障转移或跨槽业务编排。

先看清楚：多 key 命令为什么要求同槽

Redis Cluster 将 key 空间切成 16384 个 hash slot，每个主节点负责其中一部分。集群不会替客户端把一个多 key 命令拆到多个主节点上协调，所以需要同时访问多个 key 的命令，通常要求这些 key 属于同一个槽位；否则就可能得到 CROSSSLOT。

单 key 的 GET、SET 不需要为同实体设计标签。只有当一次操作确实要同时读取、修改或判断多个相关 key 时，才值得把它们绑定到同一槽位。例如读取用户资料和配额，或者在同一个事务中更新余额与版本号。

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

有效标签是 key 中第一组非空花括号之间的内容。把实体标识放进花括号，把用途放在标签外，可以同时保留可读性和同槽关系：

# 同一个用户标识放进花括号，保证两把 key 使用同一 hash tag
user:{1001}:profile
user:{1001}:quota

# 下面两把 key 的标签不同，不能假设它们同槽
user:{1001}:profile
user:{1002}:profile

# 需要协同的 key 才放在同一标签下，避免无目的地绑定数据

标签只解决“路由到同一槽位”，不自动带来业务原子性，也不替代事务、Lua 或客户端的错误处理。设计时先列出真正需要同槽的 key 集合，再决定标签粒度。

用 CLUSTER KEYSLOT 做设计期检查

不要凭 key 的字符串前缀猜槽位。官方提供的 CLUSTER KEYSLOT 会按照完整的集群哈希算法计算结果，并支持 hash tag。设计 key 规范时，直接对成组 key 查询槽位：

# 分别查看两个关联 key 的槽位，数字相同才说明它们同槽
redis-cli -c CLUSTER KEYSLOT 'user:{1001}:profile'
redis-cli -c CLUSTER KEYSLOT 'user:{1001}:quota'

# 不要把输出数字写死到程序里；槽位归属仍由集群拓扑管理
redis-cli -c CLUSTER KEYSLOT 'user:{1002}:profile'

检查的重点是“同一组是否相同”，而不是追求某个固定槽位编号。槽位最终由集群节点承载，扩缩容或重分片可能改变节点归属，但相同标签的 key 仍按同一标签计算。

避免“一个标签包打天下”的热点

最容易犯的错误是使用固定标签，例如 {all}、{global} 或 {tenant}，然后把大量无关 key 都塞进去。这样虽然多 key 命令不再跨槽，却让某个槽位承受集中读写，集群其余节点无法分担。

更稳妥的做法是按需要协同的最小实体绑定：用户级操作用 {userId}，订单级操作用 {orderId}；不参与同一次多 key 命令的计数器、缓存和日志 key 不要为了“看起来整齐”强行共用标签。若一个实体本身就是超高频热点，还要考虑把不可避免的聚合操作拆成单 key 读写或按分片标识细分标签。

速查：什么时候用、什么时候不用

常见问题

只要 key 前缀相同，就一定同槽吗？

不一定。普通前缀不会改变完整 key 的哈希输入；只有有效的花括号标签会让标签内容成为计算依据。

同一个 hash tag 会让数据更安全吗？

不会。它解决的是槽位共置，不能代替权限控制、事务语义、备份或故障处理。

标签越细越好吗？

不一定。标签要覆盖一次多 key 操作的最小必要范围；过粗产生热点，过细则无法支持需要同槽的命令。

最终可以用一句话复查设计：先列出必须同槽的 key，再为这组 key 选择实体级标签，最后用 CLUSTER KEYSLOT 检查同槽，并单独评估该标签是否会制造热点。