Redis Cluster 中 MGET 报 CROSSSLOT 错误是因为 multi-key 命令必须作用于同一哈希槽，而 key 散列到不同槽时服务端拒绝执行；解决方案包括客户端自动分组、哈希标签 {tag} 强制同槽或改用 Pipeline。
不能直接执行跨节点的 MGET，Redis Cluster 会拒绝并返回 CROSSSLOT Keys in request don't hash to the same slot 错误。这不是客户端 bug，而是集群协议强制要求：所有 multi-key 命令（MGET、MSET、DEL 等）必须作用于同一哈希槽，否则无法原子执行。
为什么 MGET 在 Cluster 中报 CROSSSLOT 错误
Redis Cluster 把 16384 个哈希槽分给多个节点，每个 key 通过 CRC16(key) % 16384 算出所属槽位。当 MGET key1 key2 key3 中的 key 散落在不同槽（即不同节点）时，服务端无法在一个节点上完成全部读取——它既不能跨节点协调，也不允许重定向后拼结果（那是客户端责任）。所以直接拒掉，避免语义模糊。
常见触发场景包括：
- 用用户 ID 直接拼
MGET user:1001 user:1002 user:1003，ID 无规律，大概率跨槽 - 批量清理日志 key，如
log:20261019:001～log:20261019:100，没加哈希标签，天然分散 - 从数据库查出一批 ID 后直接塞进
mget()，未做槽位预检查
客户端自动拆分 MGET（以 redis-py 和 Lettuce 为例）
部分成熟客户端（如 redis-py 的 RedisCluster 类、Lettuce）会在调用 mget() 时自动按槽位分组，对每组发一次 MGET，再合并结果。这能“透明”绕过 CROSSSLOT，但代价是：
- 网络往返次数 = 涉及的槽位数，不是 1 次，而是 N 次
- 总耗时取决于最慢那组的响应（串行或有限并行）
- 如果某 key 不存在，对应位置返回
None，语义和单机一致；但中间任意一组失败会导致整个mget()抛异常（取决于客户端实现）
示例（redis-py）：
from redis.cluster import RedisCluster
rc = RedisCluster(startup_nodes=[{"host": "127.0.0.1", "port": 7000}])
# key1 和 key3 跨槽 → 客户端内部拆成两组，分别请求
vals = rc.mget("key1", "key2", "key3") # 不报错，但实际发了 2 次 MGET用哈希标签 {tag} 强制 key 落同一槽
这是最可控、性能最优的方案：在 key 名中嵌入相同花括号包裹的 tag，例如 user:{1001}:profile 和 user:{1001}:settings。Redis 计算槽位时只取 {} 内内容（1001），确保它们永远在同一槽、同一节点。
- 适用场景：业务上天然有关联的 key，比如一个订单的多个字段、一个用户的多类数据
- 注意：tag 必须完全一致（包括大小写、空格），且不能嵌套，
{order:{123}}只取最外层order:{123} - 副作用：可能造成槽位热点，比如所有
user:{1}相关操作都压到一个节点，需结合业务量评估
验证方式（命令行）：
127.0.0.1:7000> cluster keyslot user:{1001}:profile
(integer) 12345
127.0.0.1:7000> cluster keyslot user:{1001}:settings
(integer) 12345不用 MGET：改用 Pipeline + 单 key GET
当 key 关系松散、无法加 tag，又不想依赖客户端拆分逻辑时，显式用 Pipeline 是最稳妥的选择：
- 明确控制每条
GET发往哪个节点（客户端自动路由） - 减少网络往返：所有
GET打包发一次，服务端顺序执行后批量回传 - 不依赖
MGET的槽位约束，天然支持跨节点
示例（redis-py）：
pipe = rc.pipeline()
for key in ["key1", "key2", "key3"]:
pipe.get(key)
results = pipe.execute() # 返回 [val1, val2, val3]，顺序严格对应注意：Pipeline 不保证原子性，但对读操作影响不大；若其中某个 key 不存在，对应位置仍为 None，行为与 MGET 一致。
真正容易被忽略的是：**哈希标签 {tag} 的生效前提是客户端和服务器都遵守同一套 slot 计算逻辑**。有些自研客户端或旧版驱动可能忽略 {}，导致你以为加了标签就安全，实际还是跨槽。上线前务必用 cluster keyslot 命令逐个验证。
