redis不限制批量命令条数，但受协议大小（默认512mb）、内存、网络及集群分片约束；mget超几百key易致超时、断连、nil混杂或crossslot错误；安全做法是客户端切分（建议≤100 key/批）、pipeline降rtt、集群确保同slot，并实现带重试与降级的批处理逻辑。
Redis 没有内置的单次批量命令条数上限，但实际受协议、内存、网络和集群约束
Redis 服务端本身不限制 MGET、MSET 或 PIPELINE 一次传多少 key/value，它只校验总请求包大小（默认 512MB）和单个字符串长度（最大 512MB）。真正卡住你的，是客户端、网络栈、内存分配或 Redis 集群的分片规则。
为什么 MGET 超过几百个 key 就开始出问题？
常见现象是超时、连接中断、返回 nil 混杂、甚至 Redis 主动断连。这不是 Redis “拒绝执行”，而是底层在扛不住：
-
MGET参数过多 → 客户端序列化后请求体膨胀，可能突破 socket 缓冲区或代理（如 Twemproxy、Envoy）限制 - 单次响应过大 → Redis 把几百个 value 拼成一个大包返回，客户端解析慢，GC 压力陡增（尤其 Python/Java）
- 阻塞主线程（Node.js/Python 同步客户端）→ 一次大
MGET卡住整个请求周期，影响并发吞吐 - 集群模式下 key 落在不同 slot →
MGET直接报错CROSSSLOT Keys in request don't hash to the same slot
怎么安全地控制批量操作规模？
别指望 Redis 配置项来“设上限”，得靠客户端主动切分 + 合理选型：
- 对
MGET/MSET：硬性建议每批 ≤ 100 个 key，生产环境可压测到 200–300，但必须监控redis-cli --latency和客户端 GC 时间 - 用
PIPELINE替代多条单命令：它不减少总数据量，但把 N 次 RTT 压成 1 次，适合混合类型操作（比如先INCR再HGETALL） - 集群环境必须确保一批 key 的 CRC16 值落在同一 slot：可用
redis-cli --cluster call查 slot，或用客户端库（如 Lettuce、redis-py-cluster）自动路由 - 避免在 pipeline 里塞上万条命令：Redis 处理大 pipeline 会暂存全部响应，内存峰值翻倍，且失败时整批重试成本高
一个够用的 Python 批处理模板（带防错）
不是教你怎么写，而是告诉你哪些细节不能省：
def safe_mget(r: redis.Redis, keys: list, batch_size=80):
if not keys:
return []
results = []
for i in range(0, len(keys), batch_size):
batch = keys[i:i+batch_size]
# 加 try 是因为网络抖动或某 batch 触发 OOM 时，别让整批挂掉
try:
res = r.mget(*batch)
results.extend(res or [])
except (redis.ConnectionError, redis.TimeoutError) as e:
# 记日志，可降级为逐个 get，或跳过该 batch
print(f"mget batch {i} failed: {e}")
results.extend([None] * len(batch))
return results
注意 batch_size=80 是经验值，不是魔法数字；如果 value 平均超过 10KB，这个值得砍半；如果用了 RedisJSON 或压缩 value，还得再调。
最容易被忽略的是集群场景下的 key 分布和错误恢复逻辑——很多人只写了“切分”，没写“失败后怎么续”，结果线上一抖就丢数据。
