Redis Cluster 中 MGET 为什么会遇到跨槽错误

Redis Cluster中的一次原生MGET要求所有键属于同一个哈希槽；键落在不同槽时会遇到CROSSSLOT错误。连接到同一节点、使用相同字符串前缀或开启重定向，都不能把跨槽MGET变成合法请求。需要原子批量读取时设计同槽键，不需要时由集群客户端拆成多次读取。

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

从单机批量读取迁移到集群

假设单机服务一次读取订单摘要和状态，切换Redis Cluster后原命令失败。这是数据分片约束，不是MGET被移除，也不是一次简单的重试就能修复。本文解读现有集群能力，不把它描述为近期发布消息。

判断的是槽而不是节点

Cluster把键映射到16384个槽。一个节点可以持有许多槽，所以“这两个键当前在同一机器上”不是同槽的证明。扩容与迁移还会改变槽的节点归属，应用不应把节点地址当作业务分组。

排障时可用CLUSTER KEYSLOT分别查看实际键名。以下命令假设redis-cli使用的端口为本地测试集群端口，不包含凭据：

# -c处理集群重定向；不能修复同一命令的跨槽键集合。
redis-cli -c -p 7000 CLUSTER KEYSLOT 'order:{471}:summary'
redis-cli -c -p 7000 CLUSTER KEYSLOT 'order:{471}:status'
redis-cli -c -p 7000 MGET 'order:{471}:summary' 'order:{471}:status' 

示例中的两个标签相同，按标签规则会同槽；没有提供虚构槽号或本机运行输出。实际环境还应确认客户端最终发送的完整键是否被框架额外加了前缀。

关联键使用明确的哈希标签

键名中有效的非空花括号片段可作为哈希标签。order:{471}:summary与order:{471}:status使用同一个标签471。普通order:前缀本身不起同槽作用，空花括号和多组花括号也不能按直觉任意选择标签，应遵循官方的首个有效配对规则。

我会把标签限定为真正共同访问的对象，例如订单ID，而不是把所有键写成{all}。后者虽然容易让批量命令通过，却会把负载集中到一个槽，削弱集群分片的价值。不同对象的标签也可能偶然哈希到同槽，不应把偶然碰撞作为业务契约。

已有键增加标签是在改变键名，旧数据不会自动迁移。切换需安排写入方和读取方、旧键过期与回退策略，避免两套命名同时造成数据分裂。

无关联键选择非原子拆分读取

如果读的是互不相关的缓存项，可使用客户端明确标注为非原子的接口。redis-py提供mget_nonatomic；下面展示一个小批次调用，REDIS_URL由环境提供：

import os
from redis.cluster import RedisCluster


def read_cards(client, keys):
    if not keys:
        return []  # 空输入不发送无键MGET。
    # 客户端可跨槽拆分；结果不代表同一时刻的全体快照。
    values = client.mget_nonatomic(keys)
    return list(zip(keys, values))  # 保留输入位置，不能先转成集合。


client = RedisCluster.from_url(
    os.environ["REDIS_URL"], decode_responses=False,
    socket_connect_timeout=5, socket_timeout=5,
)
try:
    rows = read_cards(client, ["card:31", "card:72", "card:31"])
    for key, value in rows:
        # None表示该位置没有字符串值；不把网络错误替换成None。
        print(key, value)
finally:
    client.close()  # 无论读取或输出失败都释放客户端。

示例仅供读者使用支持该接口的redis-py版本，没有执行网络请求。重复键保留重复位置；原生MGET对缺失键或非字符串值返回空值，不能把它与连接超时、权限失败混为一谈。异常应由上层按整批失败或明确的分项错误协议处理。

换成pipeline也要使用支持集群路由的客户端实现。Pipeline减少往返不等于跨节点事务，Lua脚本也不能无条件绕过同槽约束。若自行按槽分组，组内MGET可以保持组内语义，但跨组读取仍可能观察到不同时间的值。

把热点与失败语义纳入采用条件

拆分批次应限制键数量、总响应字节数和并发连接。只读请求重试通常不会重复写入，但可能得到更新后的值，导致同一批中观察时间不一致。对于需要版本一致的业务，可在数据设计中加入版本标识或改用同一个数据对象，不要只修改重试次数。

槽迁移期间，同槽多键操作也可能遇到需要重试的临时情况。应交给支持集群的客户端处理对应重定向与错误，而不是把所有错误都识别成CROSSSLOT后改走任意节点。

redis-cli -c为什么仍报跨槽？

-c帮助处理单个请求的节点重定向，不会把一条多键请求自动改写为分布式读取。

不同键在同一节点为何不能一起MGET？

原生命令约束是同槽，节点只是槽的当前拥有者。

要原子读取但键不在同槽怎么办？

需要调整数据模型或明确采用其他一致性协议。不能把客户端合并的数组等同于服务端一次原子命令。

官方资料：Cluster规范、MGET语义、redis-py集群接口。