Redis Cluster hash tag多键事务为什么没有落到同一节点怎样完成一个可复用的最小示例

Redis Cluster 多键事务没有落到同一节点，通常不是事务命令失效，而是参与操作的 key 没有共享同一个 hash slot。解决办法是把同一业务实体的稳定标识放进 key 的第一组有效花括号，例如 {user:42}:profile 和 {user:42}:orders，再用 CLUSTER KEYSLOT 验证槽号；槽号一致后，MULTI/EXEC 才能在同一节点完成。

先把相关 key 设计成同一个 hash tag

Redis Cluster 把 key space 切成 16384 个 slot。没有 hash tag 时，整个 key 参与计算；出现类似 {user:42} 的有效片段时，只计算花括号里的 user:42。因此前缀可以不同，但实体标识必须完全一致：

用 CLUSTER KEYSLOT 查出事务失败的真正原因

不要只看客户端连接到了哪个节点。客户端可能先把请求发给任意节点，再根据 -MOVED 更新路由；真正决定多键命令能否执行的是每个 key 的 slot。排查时直接比较槽号：

# 用同一个实体的两个键，确认 hash tag 产生相同槽号
redis-cli -c -h 127.0.0.1 -p 6379 CLUSTER KEYSLOT '{user:42}:profile'
redis-cli -c -h 127.0.0.1 -p 6379 CLUSTER KEYSLOT '{user:42}:orders'

# 这两个键的返回值应相同；不同就不要直接放进同一个事务
redis-cli -c -h 127.0.0.1 -p 6379 CLUSTER KEYSLOT 'user:42:profile'
redis-cli -c -h 127.0.0.1 -p 6379 CLUSTER KEYSLOT 'user:42:orders'

常见误区是把花括号当成普通装饰：{} 中间为空、只有左花括号，或 key 中的业务 ID 不一致时，Redis 会按完整 key 计算。另一个坑是 foo{bar}{zap} 只取第一组有效片段 bar，不是把两组内容拼起来。

在同槽 key 上组织一个可复用的 MULTI/EXEC

验证槽位一致后，再把事务写成业务函数。下面示例使用 redis-cli 展示最小流程；WATCH、连接复用和重试策略仍应由应用客户端负责。

# 两个 key 共享 {user:42}，因此 MULTI/EXEC 可以由同一节点处理
redis-cli -c -h 127.0.0.1 -p 6379 

如果把第二个 key 改成 {user:43}:recent，执行阶段就可能返回 CROSSSLOT Keys in request don't hash to the same slot。这不是把事务拆到多个节点执行，而是 Redis Cluster 直接拒绝这个多键请求。

什么时候不该继续扩大 hash tag

hash tag 是路由约束，不是分布式事务开关。它把同一实体的键绑定到一个 slot，便于原子更新，但也可能让高流量实体形成热点。跨用户批量统计、全局排行榜或大范围扫描，不应强行使用同一个 tag；更稳妥的做法是按 slot 或实体分批，在应用层汇总结果。

• 同一实体少量互相依赖的键：可以使用统一 tag。
• 不同实体的批量操作：拆成多个同槽批次，或改用单键命令与异步汇总。
• 写入极热的单个实体：评估分片字段、读写分离和热点缓存，别只追求事务方便。

相关问题

hash tag 会不会改变 key 的可读性？

不会。它只是改变槽位计算的输入，完整 key 仍按原样保存；前缀和后缀可以继续表达业务含义。

同一 slot 就一定在同一台物理机器吗？

在稳定拓扑下，一个 slot 由一个主节点负责，并可能有副本；故障转移或迁移期间，客户端仍要正确处理 MOVED 和 ASK。

为什么不直接给所有 key 使用同一个 tag？

这样会牺牲槽位分布，把大量读写集中到一个 slot，最终把事务便利变成吞吐和故障风险。