结论先行：「一次要读 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 倍量级——这是「命令数」换算成「连接占用」的直接账单。
四、可复用清单
- 一次读 N 个 key，N ≤ 256 且能同 slot → 一条 MGET；跨 slot → 按 slot 拆分后多条子 MGET（每 chunk ≤ 256）。
- 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——命令数下降但单分片 CPU 反升，说明你踩了坑 2。
五、一句话总结
逐 GET 付的是「命令数税」，MGET 付的是「O(N) 阻塞税 + slot 税」，Lua 是两者都付外加「服务端逻辑税」——N 小（≤256）且同 slot 选 MGET，N 大或跨 slot 选拆分 MGET，要原子选 Lua 并给 N 设硬上限。四种姿势没有绝对优劣，只有和 N、slot 分布、原子性要求三个变量匹配的取舍。