Redis Cluster pipeline 遇到 CROSSSLOT 怎么拆分

Redis Cluster 里看到 CROSSSLOT Keys in request don't hash to the same slot，先不要把所有 pipeline 都改成“一个节点一个连接”。真正的边界是：pipeline 可以包含发往不同节点的单键命令；但一条 MGET、MSET、DEL、事务或 Lua 脚本如果同时引用了不同 hash slot 的键，Redis 仍会拒绝它。官方资料可从 https://redis.io/docs/latest/ 查阅。

最稳妥的拆法是：单键命令交给支持 Cluster 的客户端按节点分发；必须多键原子处理的命令，先用 hash tag 让相关键同槽，否则按槽位拆成多条独立命令，并接受它们不再是一个原子操作。

先确认 CROSSSLOT 到底发生在哪一层

Redis Cluster 将键映射到 0 到 16383 的槽位。单键命令只有一个路由目标，客户端可以把它们拆到不同节点；而 MGET 这类多键命令需要在同一个槽位完成。pipeline 只是把多条命令一次提交，它不会把不同槽位“变成同一个槽位”。

先在目标集群上检查键，而不是凭 key 前缀猜测：

# 对成对业务键查询槽位；输出相同才适合放入同一条多键命令
redis-cli -c -h 127.0.0.1 -p 7000 CLUSTER KEYSLOT user:{42}:profile
redis-cli -c -h 127.0.0.1 -p 7000 CLUSTER KEYSLOT user:{42}:quota
redis-cli -c -h 127.0.0.1 -p 7000 CLUSTER KEYSLOT user:43:profile

前两个键的 hash tag 都是 42，应得到相同槽位；第三个键没有同样的标签，不能拿来证明“user 前缀相同就同槽”。

必须保持原子性时，用 hash tag 或同槽分组

如果业务确实要求同时读写同一个用户的资料、额度和版本号，建模时就把稳定的聚合标识放进花括号，例如 user:{42}:profile 与 user:{42}:quota。不要把变化很快、基数很大的全局字段都塞进同一个 tag，否则热点会集中到一个槽位。

如果旧键名不能迁移，应用层应先按槽位分组。每组只调用一个同槽的多键命令；跨组则是多次独立调用，不能再宣称具备跨组原子性。批量删除也同理：不要把全量 key 直接塞进一条 DEL。

把 pipeline 拆成同槽批次，而不是强行塞进一个连接

Go 客户端应使用集群客户端，让它依据 key 路由单键命令。下面的示例故意把两个单键操作放在同一个 pipeline；它们可以属于不同节点。只有当代码里出现一条真正的多键命令时，才需要额外做同槽约束。

package main

import (
    "context"
    "log"

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

func writeAndRead(ctx context.Context, rdb *redis.ClusterClient) error {
    // ClusterClient 会按键把单键命令路由到对应分片；这里不手工固定节点。
    pipe := rdb.Pipeline()
    profile := pipe.Set(ctx, "user:42:profile", "ready", 0)
    quota := pipe.Get(ctx, "user:43:quota")

    // Exec 返回的是每条命令的结果；要分别处理业务错误，不能只看总错误。
    if _, err := pipe.Exec(ctx); err != nil && err != redis.Nil {
        return err
    }
    if err := profile.Err(); err != nil {
        return err
    }
    if err := quota.Err(); err != nil && err != redis.Nil {
        return err
    }
    return nil
}

func main() {
    // 地址只作为集群发现入口；生产环境请使用实际节点和认证配置。
    rdb := redis.NewClusterClient(&redis.ClusterOptions{Addrs: []string{"127.0.0.1:7000"}})
    defer rdb.Close()
    if err := writeAndRead(context.Background(), rdb); err != nil {
        log.Fatal(err)
    }
}

若业务要读取多个不同用户的资料，不能把它们拼成一条跨槽 MGET。可以按 slot 建立键组，分别执行同槽 MGET，再按照原始 key 顺序合并返回值。这样吞吐通常更好，但结果可能在不同时间点读取，需由业务接受这种一致性变化。

用四个指标验证拆分是否真的生效

改造后不要只用“没有异常”作为结论。固定一组包含同槽键和跨槽键的测试数据，记录每批命令数量、涉及槽位数量、CROSSSLOT 次数和 P95 延迟。对比拆分前后至少保留一轮相同批量的结果：

批次大小 | 槽位数 | CROSSSLOT | P95
---------|--------|------------|----
100      | 1      | 0          | 记录实测值
100      | 2+     | 0*         | 记录实测值

* 这里的 0 只适用于单键子命令或已按槽位拆开的批次。

如果错误数降为零但 P95 上升，通常是拆得过细、网络往返增加；如果 P95 很低却出现跨槽原子性被破坏，则是把“能执行”误当成“语义等价”。生产环境还要观察热点 tag 的槽位分布和重试次数。

常见问题

pipeline 里有不同节点的 SET，会直接 CROSSSLOT 吗？

单键 SET 本身只涉及一个键，支持 Cluster 的客户端可以拆到不同节点；报错多半来自其中某条多键命令，或客户端把事务当成普通 pipeline 处理。

给所有 key 都加同一个 hash tag 可以吗？

技术上可以，但会牺牲分片均衡。只给必须一起操作的聚合对象加稳定 tag，并监测该槽位的请求量。

按 slot 拆分后还是一个事务吗？

不是。多个槽位之间只能得到多次独立调用；需要跨对象原子性时，应重新设计数据归属或改用能接受最终一致性的业务流程。