Redis Cluster hash tag多键事务为什么没有落到同一节点怎样在批处理代码中减少额外分配

我第一次把订单状态和订单明细一起放进 Redis Cluster 事务时，代码看起来没有问题：先创建事务管线，再把两个 key 放进去，最后执行。真正让人困惑的是，单 key 读写一直正常，多 key 事务却报 CROSSSLOT Keys in request don't hash to the same slot。后来又遇到过 MOVED，才发现“连到同一个集群”不等于“这几个 key 会被同一个节点处理”。

这篇只解决一个边界：让同一业务实体的多个 key 通过 Redis Cluster hash tag 共享 hash slot，并在 Go 批处理里尽量减少键列表扩容、格式化和临时对象带来的额外分配。Redis Cluster 的官方规格说明是本文的技术依据，官方地址：https://redis.io/docs/latest/operate/oss_and_stack/reference/cluster-spec/。

多键事务能否落到同一节点，先看所有 key 是否经过同一个非空 hash tag 计算出同一 slot；批处理优化则应优先复用切片容量和键构造缓冲，不能把“减少 Go 分配”误当成“跨节点事务也能自动成立”。

先把 CROSSSLOT、MOVED 和 TRYAGAIN 分开

三个错误的含义不同。CROSSSLOT 通常说明一次命令或事务中出现的 key 计算到了不同 slot，集群无法把它当成一个同槽多 key 操作。MOVED 是客户端访问了并非当前 slot 所属的节点，客户端需要刷新槽位映射并把请求交给正确节点。重分片期间，如果同一 slot 的 key 正在源节点和目标节点之间迁移，多 key 操作还可能暂时得到 TRYAGAIN。

所以，看到 MOVED 时不要马上改 key；看到 CROSSSLOT 时也不要只增加重试次数。前者偏向路由表或客户端状态，后者偏向 key 设计。Redis 官方规格还明确指出，hash tag 的目的就是让多个 key 被分配到同一 hash slot，以支持 Cluster 中的多 key 操作。

为什么两个看起来相关的 key 仍然不在同一节点

Redis Cluster 的 key 空间先经过 CRC16，再映射到 0 到 16383 的 hash slot。默认情况下，完整 key 会参与计算，所以这两个 key 的业务含义虽然都属于订单 1001，结果却可能不同：

order:1001:status
order:1001:items

修复方法是把稳定的业务实体标识放进第一对非空花括号里。计算时只取花括号内部的内容，后缀可以继续区分不同对象：

{order:1001}:status
{order:1001}:items

这两个 key 都以 order:1001 作为 hash tag，因此会落到同一个 slot。注意是“第一对满足条件的非空花括号”，不是把任意花括号都当作标签；空标签、嵌套写法和混合标签都会让结果与直觉不同，生产 key 规范最好只允许一种清晰格式。

同槽只是前提，事务边界还要由客户端维护

hash tag 解决的是路由约束，不会替你完成业务建模。一个订单的状态、明细、版本号可以共享订单 tag；跨订单的批量操作则不应为了“凑成一个事务”而硬塞进同一个 tag。那会把本来可以分散到多个 slot 的流量压向少数节点，形成热点。

下面的 Go 示例使用 github.com/redis/go-redis/v9 的 ClusterClient。关键点有两个：所有参与事务的 key 使用完全相同的 tag；事务管线中的命令只引用这批同槽 key。代码是写作示例，不把未在本机执行的输出描述成运行证据。

package main

import (
    "context"
    "fmt"

    "github.com/redis/go-redis/v9"
)

func updateOrder(ctx context.Context, client *redis.ClusterClient, orderID string) error {
    // 订单 ID 放进同一个 hash tag，保证两个 key 计算到同一 slot。
    statusKey := fmt.Sprintf("{order:%s}:status", orderID)
    itemsKey := fmt.Sprintf("{order:%s}:items", orderID)

    // ClusterClient 会按 slot 路由；事务内所有 key 必须属于同一 slot。
    _, err := client.TxPipelined(ctx, func(pipe redis.Pipeliner) error {
        // 先写状态，再追加明细；两条命令由同一个 MULTI/EXEC 边界提交。
        pipe.Set(ctx, statusKey, "ready", 0)
        pipe.RPush(ctx, itemsKey, "item-1")
        return nil
    })
    if err != nil {
        // CROSSSLOT 要回到 key 设计排查，MOVED/TRYAGAIN 则交给客户端重试策略。
        return fmt.Errorf("update order %s: %w", orderID, err)
    }
    return nil
}

如果两个 key 一个写成 {order:1001}:status，另一个写成 {orders:1001}:items，它们的 tag 已经不同，事务仍会失败。不要把 tag 版本化成随机值，也不要让同一个业务实体的 tag 在不同代码路径中采用不同大小写或编码。

批处理里怎样减少额外分配

解决同槽之后，我才开始看批处理的分配热点。最容易被忽略的是在循环里反复使用 fmt.Sprintf、让 []string 不断扩容，或者每一批都重新创建完全相同容量的列表。这些开销不会改变 Redis 的 slot，但会增加 Go 端 GC 压力和请求尾延迟。

一个稳妥的方向是：预留批次容量，复用 key 列表；使用 strconv.AppendInt 代替通用格式化；把批量大小作为配置而不是无限增长。示例只展示对象构造和批次边界，实际执行仍要由支持 Cluster 路由的客户端完成。

package batch

import (
    "strconv"
)

// buildOrderKeys 复用调用方传入的切片容量，避免每批从零开始扩容。
func buildOrderKeys(dst []string, orderIDs []int64) []string {
    // 保留原底层数组；长度清零后只覆盖本批有效元素。
    dst = dst[:0]
    for _, id := range orderIDs {
        // 先准备一个小字节缓冲，减少 fmt.Sprintf 的通用格式化开销。
        buf := make([]byte, 0, 32)
        buf = append(buf, "{order:"...)
        buf = strconv.AppendInt(buf, id, 10)
        buf = append(buf, "}:status"...)
        // 转成字符串后保存进本批列表；切片本身的扩容由调用方控制。
        dst = append(dst, string(buf))
    }
    return dst
}

// splitBatches 按固定上限切分，避免一次事务把过多 key 压到一个 slot。
func splitBatches(ids []int64, batchSize int) [][]int64 {
    // 非法批量值直接返回空结果，避免调用方进入死循环。
    if batchSize  len(ids) {
            end = len(ids)
        }
        // 子切片复用 ids 的底层数组；若要跨 goroutine 保存，请先复制。
        batches = append(batches, ids[start:end])
    }
    return batches
}

这里仍然会为每个最终字符串产生必要的内容存储，所谓“减少额外分配”不是宣称零分配。真正值得避免的是格式化器、列表反复扩容和不受控的批次切分。若 key 会被长期缓存，应该明确字符串生命周期；如果要把缓冲继续复用，就不能让已经保存的字符串依赖后续会被覆盖的内存。

哪些设计会让 hash tag 反而变成性能问题

第一种是 tag 选择过粗，例如所有订单都使用 {orders}。这样虽然任何订单之间都能放进同一事务，但所有写请求都会集中到同一个 slot 和节点，集群的横向扩展收益被抵消。更合理的是以业务实体为粒度，例如订单 ID、购物车 ID 或用户 ID，但仍要结合热点用户和流量分布观察。

第二种是把不相关的数据强行绑定。订单状态和订单明细需要原子更新时可以共享 tag；全站计数器、推荐列表和订单明细没有必要共用一个 tag。跨实体聚合应该考虑拆成多个操作、异步汇总或换用适合跨 slot 的数据结构，而不是让一个巨大事务承担所有一致性。

第三种是忽略重分片期间的边界。官方规格说明中，多 key 操作在 slot 迁移时可能暂时不可用，遇到 TRYAGAIN 需要由客户端按退避策略重试；这和普通 MOVED 的槽位映射刷新不是一回事。

上线前我会检查的五个问题

1. 同一事务里的每个 key 是否使用完全一致的、非空的 hash tag？
2. 事务是否只覆盖一个业务实体，而不是把多个实体绑定到同一热点 slot？
3. Cluster 客户端是否会维护 slot 映射，并正确处理 MOVED 和 ASK？
4. 批处理的 key 列表是否预分配容量，批次大小是否有上限？
5. 重分片、热点节点和 TRYAGAIN 的重试是否有日志与指标，而不是无限重试？

我的经验是先把 key 规范写成可读的约定，再把同槽事务封装成一个小函数，最后才去做分配优化。这样 CROSSSLOT、热点和 GC 压力分别有清晰的归因，不会因为一次“优化”同时改变路由、事务和批处理行为。

相关问题

Redis Cluster 的 hash tag 一定要放在 key 开头吗？

不一定。Redis 关注的是 key 中第一对符合规则的非空花括号，标签可以出现在前缀之后；但团队最好统一格式，避免可读性和排查成本上升。

同一个 hash tag 能保证跨节点强一致吗？

不能。它让相关 key 进入同一个 slot，从而具备使用同槽多 key 操作的前提；复制延迟、故障转移、重试和业务失败处理仍然需要单独设计。

只用 Pipeline 不用事务能解决 CROSSSLOT 吗？

不能从根本上解决。Pipeline 可以减少网络往返，但其中的多 key 命令仍受 Cluster 的 slot 约束；是否使用事务还要看你是否需要 MULTI/EXEC 的原子提交语义。