Redis Cluster跨槽批量读取的拆分方案

我在把单机 Redis 的批量读取迁到 Redis Cluster 时，最先遇到的不是客户端 API 变了，而是原来的“把一批 key 交给一次 MGET”不再成立：这些 key 可能落在不同 hash slot，服务端会拒绝跨槽多键请求。比较稳妥的拆分方案是由客户端先计算每个 key 的 slot，按 slot 分组后分别读取，最后依据原始下标合并结果。

官方地址：https://redis.io/

先区分同槽读取和跨槽读取

Redis Cluster 将键空间划分为 16384 个 hash slot，客户端根据 key 计算目标 slot，再把请求发往负责该 slot 的节点。像 MGET user:1 user:2 这样的请求，如果两个 key 不在同一 slot，就不应假定服务端会替我们跨节点聚合。

如果业务键写成 profile:{1001} 和 orders:{1001}，花括号里的内容会作为 hash tag 参与计算，两者可以落在同一 slot。这适合需要一次多键操作的同一聚合根；对于用户、商品、订单等天然分散的批量查询，则更适合客户端拆分。

按 slot 保存原始下标，再分别读取

分组时不要只保存 key 字符串，至少要保存原始位置。这样同一个 slot 里的请求可以使用 MGET，不同 slot 之间由客户端并行调度，返回后仍能还原成调用方期待的顺序。下面的 Go 代码展示的是拆分骨架，Slot、MGet 和拓扑刷新由实际使用的 Cluster 客户端提供。

type item struct {
    index int    // 保存输入下标，合并时按原顺序回填
    key   string // 保存原始 key，便于定位单个读取结果
}

groups := make(map[uint16][]item)
for index, key := range keys {
    slot := client.Slot(key) // 使用客户端拓扑计算 hash slot
    groups[slot] = append(groups[slot], item{index: index, key: key})
}

result := make([][]byte, len(keys))
for slot, items := range groups {
    values, err := client.MGet(ctx, slot, keysOf(items)) // 同一slot内批量读取
    if err != nil {
        return nil, fmt.Errorf("read slot %d: %w", slot, err) // 保留slot上下文
    }
    for position, value := range values {
        result[items[position].index] = value // 不按节点完成顺序拼接
    }
}

生产代码通常会把各个 slot 组投递到受限的 worker pool，而不是为每组都创建 goroutine。并行度太高会同时放大连接数、响应体和客户端内存；并行度太低则会让跨节点批量读取退化成串行网络往返。

把 MOVED、TRYAGAIN 和部分结果分开处理

集群拓扑变化时，节点可能返回 MOVED，表示客户端的 slot 映射已过期；客户端应刷新拓扑并重发该组。resharding 期间还可能出现 TRYAGAIN，这更像暂时不可用，应使用有限次数和退避重试。两者都不能用“整批无限重试”处理，否则一个迁移中的 slot 会拖住所有无关分组。

合并层建议维护“成功值、缺失值、失败组”三种状态。某个 key 不存在时保留空值位置；某个 slot 组最终失败时返回带 slot 和 key 范围的错误，让上层决定降级，而不是把缺失值误当成读取失败。

什么时候改用 hash tag

如果一次操作必须同时读取或更新一组强相关 key，可以把稳定的业务标识放进 hash tag，例如 cart:{42}:items 和 cart:{42}:summary。这样能保留同槽多键命令的语义，但不是免费优化：大量 key 共用同一个 tag 会形成 slot 热点，影响该节点的吞吐和故障域。

我的判断是：查询只是为了减少调用次数，就采用“按 slot 分组 + 受限并行 + 原序合并”；需要事务、脚本或强一致多键语义，才从数据模型层面评估 hash tag。两种方案解决的是不同问题。

常见问题

跨槽读取能不能直接循环执行 GET？

可以作为最小兼容方案，但网络往返会显著增加。优先按 slot 分组，在每组内使用批量读取，再根据实际延迟和响应大小调整并行度。

为什么用了 hash tag 还要关注性能？

hash tag 让相关 key 同槽，也意味着它们共享同一个节点和 slot 的资源。tag 设计应围绕业务聚合边界，避免把全站热点都固定到一个 tag。