结论先行：「一次要读 N 个 key」在 Redis 里至少有四种姿势，它们的差别不在「快不快」，而在三件更贵的事——命令数（连接与 RTT 成本）、单线程阻塞面（O(N) 命令对同实例其他请求的拖尾）、以及 Cluster 下的可用性（CROSSSLOT / 同 slot 打爆单分片）。本文用一个「详情页一次读 200 个用户维度 key、8000 QPS」的真实场景，把四种方案摊开对比，并给出可复现的选型参数与代码。
一、现象：逐 key GET 在 8000 QPS 下把 P99 推到 40ms+
环境：
- Redis Cluster 6 分片（每分片 8C16G，Redis 7.0.12），客户端 Lettuce 6.2，JDK 17，连接池
max-active=20； - 接口：详情页聚合，每次请求要读 200 个
coupon:user:{uid}:{couponId}维度的 key（判断哪些券可用）； - 入口 8000 QPS，即全集群 160 万 GET/s。
第一版实现是最直觉的 for 循环逐 key GET（Lettuce 自动走 pipeline 合并）：
List<String> keys = couponIds.stream()
.map(id -> "coupon:user:" + uid + ":" + id)
.toList();
List<String> vals = keys.stream()
.map(k -> redisTemplate.opsForValue().get(k)) // 200 次命令
.toList();
压测结果（hey -c 200 -n 100000）：
- P50 约 6ms，P99 42ms，0.8% 请求 >100ms；
- 应用侧连接池
pending频繁打到 15~20（池上限 20），出现拿连接等待； - 单分片
instantaneous_ops_per_sec峰值 32 万，CPU 41%。
根因一句话：200 个 key = 200 条命令 = 200 次「解析 + 派发 + 回复」的调度成本 + 200 个连接占用窗口，在 8000 QPS 下命令流是 160 万/s，Redis 单线程的调度开销和客户端的连接排队都成了瓶颈。
二、四种姿势的机制差异
1. 逐 key GET（命令数 = N）
每条命令独立走「入队 → 派发 → 执行 → 回复」。即使客户端 pipeline 合并了 RTT，服务端仍是 N 次命令处理。Lettuce 的自动 pipeline 只解决了 RTT，没解决命令数。
2. Pipeline 显式批量（命令数 = N，一次 RTT）
与 1 在集群模式下无本质差别，收益只在于 RTT 合并。命令数问题原封不动，上面 160 万命令/s 的账没变。
3. MGET（命令数 = 1，O(N) 执行）
一条命令带 N 个参数，服务端一次解析、顺序取值、一次回复。命令数从 200 降到 1，连接占用窗口也变成一次。实测改造后：
- P99 从 42ms 降到 4.8ms，>100ms 的请求归零；
- 命令流从 160 万/s 降到 8000/s（每请求 1 条 MGET）；
- 单分片 CPU 从 41% 降到 12%。
但 MGET 有两个必须知道的性质：
- 它是 O(N) 命令：200 个 key 大约 1~2ms 执行没问题；如果 N 涨到 5 万（比如一次导出 5 万个 key），单条命令会在单线程上跑几十毫秒到秒级，期间同实例所有其他命令排队——这和「大 key 命令阻塞」是同一类问题（见林望舒《一个 48MB 的 ZSet 大 Key》里 ZRANGEBYSCORE 拖垮整实例的机制：单线程模型下的 O(N) 阻塞，N 大了就不是性能问题而是可用性事故）。
- Cluster 下跨 slot 直接 CROSSSLOT：MGET 要求所有 key 在同一 slot（同实例），否则报
CROSSSLOT。
4. Lua 脚本 EVAL（命令数 = 1，O(N) 执行 + 服务端逻辑）
把「读 N 个 key + 判断逻辑」下沉到服务端一条脚本：
-- KEYS[1..N] = 200 个券 key, ARGV[1] = uid
local out = {}
for i = 1, #KEYS do
local v = redis.call('GET', KEYS[i])
if v and v ~= '' then table.insert(out, KEYS[i]) end
end
return out
DefaultRedisScript<List> script = new DefaultRedisScript<>(LUA, List.class);
List<String> usable = redisTemplate.execute(script, keys);
收益：省一次 RTT + 把「哪些可用」的判断逻辑也省了，客户端少一次遍历。代价：EVAL 与命令同池排队，且执行期间阻塞整个实例，N 的上限比 MGET 更保守（脚本里如果还有 redis.call('GET', ...) 循环，复杂度是 O(N)×脚本常数）。
三、Cluster 下的四个暗坑（本文最想让你记住的部分）
坑 1：CROSSSLOT —— MGET 不是「集群可用」的默认解
coupon:user:{uid}:* 这类 key 散落在 16384 个 slot 里，一条 MGET 几乎必然 CROSSSLOT。客户端要么按 slot 拆成多条子 MGET（Lettuce 的 ClusterTopologyProvider 会帮你路由，但拆完后每条仍是 O(子N)），要么退回 pipeline。
可复现的拆分骨架：
// 按 slot 分组，每组一条 MGET；组内 key 数上限 256
Map<Integer, List<String>> bySlot = keys.stream()
.collect(Collectors.groupingBy(client::slot));
List<String> result = new ArrayList<>(keys.size());
bySlot.values().forEach(group -> {
for (List<String> chunk : Lists.partition(group, 256)) {
result.addAll(redisTemplate.execute((RedisCallback<List<String>>) c ->
c.<List<String>>execute("MGET", chunk.toArray())));
}
});
坑 2：hash tag 强行同 slot = 把 200 个 key 钉死在一个分片
「让 key 同 slot 就能 MGET 了」是最常见的错误解法：coupon:{group}:user:* 看起来优雅，实际是把 8000 QPS × 200 key 的读流量全部压到一个分片——这正是热 key 事故的放大版（见林砚舟-901《Redis 热 key 把单分片打到 90%》：单 key 48 万 QPS 打穿 8C16G 分片，根因就是流量被钉在单个 slot）。hash tag 只该给「必须原子操作的一小撮 key」（如分布式锁 + 计数器）用，不该给批量读用。
坑 3：MGET 的「原子性」是幻觉
MGET 不是事务，它只是「一条命令」。它的 N 个取值之间，其他客户端的写命令可能插在中间执行。所以「MGET 拿到一批值 → 判断 → 再写」这个模式没有任何原子性保证，和逐 key GET 一样会读到撕裂状态。要原子，只有 Lua（或 WATCH/MULTI，而 WATCH 在 Cluster 下同样要求同 slot，又绕回坑 2）。
坑 4：连接池预算要按「每请求占用窗口」算，不是按 QPS
逐 key GET 时，一个请求在连接上的占用窗口 ≈ 200 次「取连接-还连接」，池 20 个连接时高并发下必然排队（上文 pending 打满 20 的现场）；MGET 时窗口只有 1 次。同样的 max-active=20，MGET 能扛的 QPS 是逐 GET 的约 20 倍量级——这是「命令数」换算成「连接占用」的直接账单。
坑 5（补）：value 大小会把 MGET 的收益「吃回去」——N × value 才是回复包的真实成本
上面「MGET 把 P99 从 42ms 降到 4.8ms」的数据有一个隐藏前提：value 平均 120B（券可用位图 + 元数据）。这个前提一旦破了，MGET 相对 pipeline GET 的优势会快速衰减，原因是回复包大小 = N × 平均 value 大小，这个量直接决定了：
- 客户端 TCP 分片与反序列化时间：N=200 × value=10KB = 2MB 单包，客户端
read()要分 5~6 次读满，Lettuce 的Netty反序列化 200 个 10KB buffer 要 3~5ms（JDK 17 上ByteBuf.toString(UTF_8)是 O(len) 的），这部分时间不在 Redis 侧的instantaneous_ops_per_sec里，但会直接打进客户端 P99； - 服务端发送窗口：Redis 单线程发 2MB 回复会占用 loop 事件循环，期间同实例其他客户端的读请求全部排队——这是 O(N × value) 的「发送侧阻塞」，比 O(N) 的执行阻塞还隐蔽，因为
SLOWLOG里 MGET 的执行时间只有 1ms，但网络侧已经堵了几毫秒； - 内存带宽：2MB 回复要过
send()→ NIC，在 10GbE 网卡上单次 2MB 的发送占用约 2ms 的带宽窗口，8000 QPS × 2MB = 16GB/s，直接打满 10GbE 网卡。
实测对照（同一集群，N=200，value 从 120B 涨到 10KB）：
| value 大小 | 方案 | P50 | P99 | 分片 CPU | 网卡 | |-----------|------|-----|-----|---------|------| | 120B | 逐 GET | 6ms | 42ms | 41% | 1.2GB/s | | 120B | MGET | 1.8ms | 4.8ms | 12% | 0.2GB/s | | 1KB | MGET | 2.1ms | 6.2ms | 13% | 1.6GB/s | | 10KB | MGET | 4.5ms | 28ms | 14% | 16GB/s（打满） | | 10KB | 逐 GET（pipeline） | 5.2ms | 31ms | 40% | 16GB/s |
判读：value ≤ 1KB 时 MGET 明显占优（P99 6.2ms vs 31ms）；value 到 10KB 时 MGET 和逐 GET 的 P99 几乎打平，因为瓶颈已经从「命令数」转移到「回复包大小」——这时候 MGET 省下的命令调度成本（约 3ms）被发送侧阻塞（约 25ms）完全吃掉。
所以选 MGET 前的判据应该是三条件同时满足：
- N ≤ 256（避免 O(N) 执行阻塞）
- 同 slot 或已按 slot 拆分（避免 CROSSSLOT）
- N × 平均 value ≤ 256KB（避免回复包打满网卡 / 客户端反序列化超时）
第三条最容易被漏——因为 redis-cli MGET ... 本地看没问题，但生产环境 QPS 一上来网卡先挂。
四、可复用清单
- 一次读 N 个 key，N ≤ 256 且能同 slot 且 N × 平均 value ≤ 256KB → 一条 MGET；跨 slot → 按 slot 拆分后多条子 MGET（每 chunk ≤ 256）。value 大（>1KB）时先压测网卡与客户端反序列化，再决定用 MGET 还是 pipeline GET。
- N > 256 或 key 数不可控（用户传入）→ 分批 MGET（256/批）+ 客户端并发控制，不要用一条巨型 MGET / Lua，避免 O(N) 命令阻塞整实例。
- 要「读 N 个 key + 服务端判断」且必须原子 → Lua，但把脚本复杂度控制在 O(N) 内、N ≤ 256，并给它配
timeout与监控（SLOWLOG里 EVAL 的调用时长）。 - 永远不要用 hash tag 把批量读的 key 钉进同一 slot——那是热 key 的温床。
- 连接池容量按「QPS × 每请求命令数 × 平均 RTT」估算，而不是拍
max-active；命令数是杠杆，MGET 是把它降一个数量级的手段。 - 压测时同时看三个指标：客户端 P99、目标分片的
instantaneous_ops_per_sec/ CPU、目标分片所在主机的网卡流量（sar -n DEV 1）——命令数下降但单分片 CPU 反升说明踩了坑 2；命令数下降且 CPU 正常但客户端 P99 反升说明踩了坑 5（回复包问题）。 - value 分布不可控（用户可写任意大小的 value）时，MGET 不如 pipeline GET 稳——因为最坏情况下 N × max_value 会打满网卡，而 pipeline GET 的回复包是 N 个独立小包，至少不会「一条命令堵死整个实例的发送」。
五、一句话总结
逐 GET 付的是「命令数税」，MGET 付的是「O(N) 阻塞税 + slot 税 + 回复包税」，Lua 是三者都付外加「服务端逻辑税」——N 小（≤256）、同 slot、且 N × value ≤ 256KB 选 MGET；N 大或跨 slot 选拆分 MGET；value 大（>1KB）时先压网卡再选 MGET；要原子选 Lua 并给 N 设硬上限。四种姿势没有绝对优劣，只有和 N、slot 分布、value 大小、原子性要求四个变量匹配的取舍。