Redis Cluster 哈希标签怎么让多键操作落在同一槽

Redis Cluster 里，想让两个或多个 key 支持同一次多键操作，关键不是把请求重复发给所有节点，而是让这些 key 的哈希槽相同。最直接的做法是给同一业务实体使用同一个哈希标签，例如 order:{u42}:items 和 order:{u42}:count。Redis 只对花括号中首个有效、非空的片段计算槽位。

官方地址：https://redis.io/docs/latest/operate/oss_and_stack/reference/cluster-spec/

哈希标签真正改变了什么

没有标签时，Redis Cluster 默认按 CRC16(key) mod 16384 计算槽位，完整 key 的每个字符都可能影响结果。哈希标签提供了一个例外：只要 key 含有有效的 {...}，参与计算的就是第一对有效花括号之间的内容。因此，业务前缀可以继续表达数据类型，标签则负责表达“这些 key 属于同一个实体”。

按业务实体设计一组稳定 key

标签应代表一次多键操作真正共享的实体，而不是随手取一个全局词。订单详情、订单计数和订单待处理集合可以共享订单号；如果把所有用户都写成 {user}，虽然容易同槽，却会把大量访问压到同一个槽和节点。

我更倾向于先写命名契约，再让代码只能通过一个构造函数生成 key：

package keyspace

// OrderKeys 让同一订单的多种数据共享 orderID 标签。
// 标签粒度必须足够分散，不能把所有订单收敛成一个固定词。
func OrderKeys(orderID string) (items, count string) {
    // 前缀区分数据用途，花括号只承担槽位绑定职责。
    tag := "{" + orderID + "}"
    return "order:" + tag + ":items", "order:" + tag + ":count"
}

不要把用户输入未经约束地塞进标签。订单号中的花括号会改变 Redis 的解析边界，空订单号还会让标签失效。生产代码应先校验允许的字符和长度，并为旧 key 保留迁移或双读方案。

用 CLUSTER KEYSLOT 验证，而不是凭眼睛判断

key 看起来拥有相同前缀，不代表一定同槽；真正需要比较的是 Redis 计算出的槽位。可以在连接到 Cluster 的节点上逐个查询：

# 两个 key 使用同一个 {u42} 标签，预期返回相同槽号
redis-cli -c -h 127.0.0.1 -p 6379 CLUSTER KEYSLOT 'order:{u42}:items'
redis-cli -c -h 127.0.0.1 -p 6379 CLUSTER KEYSLOT 'order:{u42}:count'

# 没有共同标签时，先确认槽位是否不同，再决定是否拆分操作
redis-cli -c -h 127.0.0.1 -p 6379 CLUSTER KEYSLOT 'order:u42:items'
redis-cli -c -h 127.0.0.1 -p 6379 CLUSTER KEYSLOT 'order:u42:count'

同槽是多键命令的必要条件之一。它不等于命令已经成功：客户端仍要处理 -MOVED、-ASK，并确认命令本身支持这些 key 的组合。跨槽时，优先拆成按槽执行的批次或改用单键命令，不要用标签掩盖不适合聚合的数据模型。

三个容易被忽略的边界

1. 标签热点：同一标签下的 key 越多，相关请求越集中。按用户、订单或租户选择粒度时，要结合访问分布，而不是只追求“一次命令能拿齐”。
2. 花括号规则：foo{{bar}}zap 取首个花括号后的 {bar，嵌套写法不是自然语言意义上的“内层标签”。
3. 扩容与迁移：槽会在节点之间迁移，标签只固定 key 的槽号，不固定物理节点。扩容期间客户端仍需正确处理重定向。

上线检查可以压缩成四项：真实 key 成对执行 CLUSTER KEYSLOT；标签值不会集中成热点；旧命名有迁移策略；多键命令的错误与重试由客户端负责。满足这四项，哈希标签才是可维护的分片契约。

常见问题

只要两个 key 的前缀相同就会同槽吗？

不会。没有有效哈希标签时，整个 key 参与 CRC16 计算；应使用相同的非空标签并实际查询槽位。

哈希标签能让跨槽事务自动成功吗？

不能。它只把采用相同标签的 key 放入同一槽，事务、脚本和多键命令仍受客户端与命令规则约束。

扩容后要不要重新生成标签？

通常不需要。标签决定逻辑槽位，槽位到节点的映射可以变化；扩容时重点是让客户端处理迁移期间的重定向。