Redis Cluster 跨槽位事务为什么不能直接使用 MULTI

Redis Cluster 里，MULTI 不能把多个哈希槽上的键“临时锁”到一起。事务命令会先由客户端路由到一个节点；如果事务中的键不在同一槽位，服务端就无法在一个节点内完成这组多键操作，常见结果是跨槽错误，而不是换成 EXEC 就能解决。

为什么 MULTI/EXEC 会遇到跨槽限制

单机 Redis 的事务是在一个实例内排队并执行的。Redis Cluster 为了让节点各自负责自己的数据，不使用代理把一个请求转发到多个节点；客户端需要根据键的槽位直接找到目标节点。官方集群规范也明确，多键操作只有在所有键映射到同一 hash slot 时才可用。

例如下面的写法同时修改订单和库存：

# 这两个键没有共享哈希标签，可能落在不同槽位
redis-cli -c MULTI
redis-cli -c HSET order:1001 status paid
redis-cli -c DECR stock:sku-9
redis-cli -c EXEC

问题不在 MULTI 的语法，而在一组命令的键集合跨越了节点边界。客户端即使能处理普通命令的 -MOVED 重定向，也不能把一个已经排队的事务安全地拆到多个节点执行。

先理解 16384 个槽和哈希标签

Redis Cluster 把键空间分成 16384 个槽，普通键按 CRC16(key) mod 16384 计算位置。键名前缀相同并不代表槽位相同，所以 order:1001 和 stock:sku-9 不能仅凭业务上“属于同一订单”就期待同槽。

哈希标签是专门为这种关联场景提供的命名规则：如果键中存在一对有效的大括号，只有其中的内容参与槽位计算。因此下面两把键会进入同一槽：

# {order-1001} 是哈希标签，两个完整键共享同一槽位
redis-cli -c HSET "{order-1001}:detail" status paid
redis-cli -c DECR "{order-1001}:stock:sku-9"

# 只要标签内容不同，就不能假设同槽
redis-cli -c GET "{order-1001}:detail"
redis-cli -c GET "{order-1002}:detail"

标签应放在真正需要一起操作的业务聚合标识上，而不是把所有键都写成同一个固定标签。后者会让大量请求集中到一个槽，牺牲集群的分散能力。

键名怎么改，才能保留单槽事务

改名后仍要确认所有读写路径都使用同一套规则，包括缓存删除、过期设置和后台任务。可以在客户端测试中把同一事务的键打印出来，再用客户端提供的槽位计算方法确认它们一致；不要只检查字符串前缀。

无法同槽时，事务边界要回到业务层

有些业务键天然属于不同租户或不同聚合，强行加同一个标签反而会造成热点。这时不要用重试掩盖跨槽错误，可以把一个大事务拆成多个单槽动作，并为每一步设计可重放的状态。

例如先在订单槽内写入“待扣库存”，再调用库存槽的扣减动作；库存成功后把订单改为已支付，失败则由补偿任务把订单恢复为可重试状态。关键不是让 Redis 模拟分布式事务，而是让每个动作都有唯一业务号、明确状态和幂等判断。

// 每个跨槽动作使用同一个业务号，重试不会重复扣减
type StockResult struct {
    RequestID string // 用于幂等去重
    Accepted  bool   // 记录库存动作是否已受理
}

// 真实项目中这里应由库存服务在自己的槽位内完成检查与扣减
func applyStock(requestID, sku string, count int) StockResult {
    // 先检查 requestID，再执行单槽 MULTI/EXEC
    return StockResult{RequestID: requestID, Accepted: true}
}

如果业务必须保证强原子性，就重新评估数据模型：把必须一起变更的数据放入同一个聚合，或者改用更适合跨分片协调的存储方案。Redis Cluster 的扩缩容和重分片也会移动槽位，但不会改变“同一组多键命令必须同槽”的设计前提。

上线前的 Redis Cluster 检查清单

• 检查客户端是否启用了 Cluster 模式，并能处理 -MOVED 与 -ASK。
• 检查每个 MULTI/EXEC、多键删除、批量读取的键是否共享有效哈希标签。
• 避免空标签、嵌套大括号和标签内容过于固定；命名规则要有单元测试。
• 重分片期间观察客户端拓扑刷新、重试和超时，不要把跨槽错误当成偶发网络抖动。
• 对拆分后的业务动作保存请求号和状态，验证重复投递、部分成功及补偿路径。

相关问题

把所有键都加上同一个 {global} 可以吗？

技术上可能同槽，但会把流量和数据集中到一个槽，失去 Cluster 的水平分散能力。标签应绑定业务聚合，而不是全局常量。

客户端自动重定向后，跨槽事务会自动成功吗？

不会。重定向只能帮助客户端找到某个槽的节点，不能把不同节点的事务合并成一个原子执行单元。

用 Lua 就能绕过跨槽限制吗？

不能把集群边界消除。脚本涉及多个键时同样需要满足集群的键路由约束，优先先修正键设计或业务边界。