RedisJSON 怎么一次读取多个 Key 的同一路径

如果多个 RedisJSON 文档拥有相同结构，逐个执行 JSON.GET 不仅代码重复，还容易在并发读取时把不同版本的数据混在一起。读取“多个 Key 的同一路径”时，直接使用 JSON.MGET：把 Key 依次写在前面，把一个 JSONPath 放在最后，返回数组的位置就与输入 Key 的顺序对应。

官方地址：https://redis.io/docs/latest/commands/json.mget/

JSON.MGET 的正确顺序是什么

命令的形状是 JSON.MGET key [key ...] path。前面可以有一个或多个 Key，最后只放一个 JSONPath。比如两个文档都保存了 profile.name，可以一次取出这两个名字：

# 先给两个文档写入相同结构，便于观察返回位置
JSON.SET user:101 $ '{"profile":{"name":"林岚","level":3}}'
JSON.SET user:102 $ '{"profile":{"name":"周远","level":4}}'

# Key 顺序是 user:101、user:102，最后一个参数才是共同路径
JSON.MGET user:101 user:102 $.profile.name

这条命令的结果可以理解为 ["林岚", "周远"]：第一个元素对应 user:101，第二个元素对应 user:102。不要把结果数组按字典序重新排序，否则读者或程序就无法知道某个值来自哪个 Key。

怎样保证返回值和 Key 一一对应

批量读取的“资产”有两个：输入 Key 列表和返回数组。最稳妥的做法是保留原始 Key 列表，用下标把两者重新配对，而不是只把返回值当成一个无名数组。

# 下面的数组顺序必须和 JSON.MGET 的 Key 顺序完全一致
keys=(user:101 user:102 user:103)

# 路径固定放在最后，返回数组的下标与 keys 下标相同
JSON.MGET "${keys[@]}" $.profile.name

在应用代码里，可以把每个返回项包装成 {key, value} 这样的结构。这样即使其中一个 Key 缺失，日志和业务处理仍能指出具体对象，而不是只看到“第 2 项为空”。如果客户端库把 RESP 返回值解码成字符串，还要注意 JSON 值可能是 JSON 文本；不要把字符串 "null" 和协议层的空值混为一谈。

遇到 null 时先判断是哪一种缺失

JSON.MGET 返回数组中的 null，常见原因是 Key 不存在，或者 Key 存在但指定路径不存在。两种情况的修复动作不同：前者要判断数据是否尚未创建，后者要检查 JSONPath 或文档结构是否发生变化。

# user:103 不存在时，第三个返回位置会是 null
JSON.MGET user:101 user:102 user:103 $.profile.name

# Key 存在但没有 profile.name 时，同样要检查该位置对应的文档结构
JSON.SET user:104 $ '{"profile":{"nickname":"小周"}}'
JSON.MGET user:104 $.profile.name

还有一种容易误判的情况：路径匹配到多个值时，返回的元素可能是一个 JSON 数组。例如使用递归路径 $..name，同一个文档里多个层级的 name 都可能被选中。这时“一个 Key 对应一个返回元素”仍然成立，但这个元素内部可能包含多个值。

Redis Cluster 中多 Key 怎样避免跨 slot

在 Redis Cluster 中，JSON.MGET 一次涉及多个 Key。官方文档明确提示：指定的 Key 需要落在同一个 hash slot；当 Key 分布在不同分片时，结果可能报 CROSSSLOT，也可能因为部署形态而出现部分结果。因此，不能只在单机环境测试通过后就把任意 Key 列表直接发到集群。

# 共享 {42} 的 Key 会使用同一个 hash tag，适合放进同一批多 Key 读取
JSON.SET user:{42}:101 $ '{"profile":{"name":"林岚"}}'
JSON.SET user:{42}:102 $ '{"profile":{"name":"周远"}}'
JSON.MGET user:{42}:101 user:{42}:102 $.profile.name

# 没有共享 hash tag 时，不要假设两个 Key 一定在同一 slot
JSON.MGET user:101 order:9001 $.id

hash tag 不是“让所有数据都放到一个节点”的万能开关，它只是从 Key 名中选出用于计算 slot 的片段。业务上确实需要一起读取的对象，可以设计一致的 tag；如果 Key 数量很大或对象天然分散，更适合按 slot 分组后分批执行，并在应用层合并结果。

把读取边界落实到客户端代码

如果请求来自用户或上游服务，不要让外部输入直接拼成任意路径和无限 Key 列表。可以在应用层固定允许的 JSONPath、限制 Key 数量，并为每个结果保留 Key 名。下面用 Go 展示核心配对逻辑；Redis 客户端的具体调用方式可按项目使用的库替换。

package main

import "fmt"

func pair(keys []string, values []any) []map[string]any {
	// 只配对服务端实际返回的长度，避免异常响应导致下标越界。
	limit := len(keys)
	if len(values) 

这段逻辑没有把 null 当成失败重试信号：缺失文档可能是正常的首次创建，也可能是数据迁移遗漏，应该交给业务规则判断。只有确认是临时通信失败时，才考虑重试；固定的路径错误、Key 设计错误和跨 slot 错误，应先修正原因。

常见问题

JSON.MGET 可以为不同 Key 指定不同路径吗？

不能按一次命令为每个 Key 分别传不同路径。它的参数形状是多个 Key 加一个共同路径；不同路径需要拆成多次读取，或重新设计文档结构。

返回数组中的 null 能说明 Key 一定不存在吗？

不能。Key 不存在和路径不存在都可能得到 null，需要结合 Key 存在性或文档结构检查来区分。

用了 hash tag 就一定能保证读取成功吗？

hash tag 只能帮助相关 Key 落到同一 slot，还要保证 Key 名确实使用了相同 tag、文档路径正确，并考虑客户端和 RedisJSON 版本的支持边界。

什么时候不应该使用 JSON.MGET？

当 Key 数量很大、对象天然分散在多个 slot，或每个对象需要不同路径时，按 slot 分批、单 Key 读取或调整数据模型通常更容易控制错误和延迟。