Redis Pipeline 为什么能提高吞吐？能保证原子性吗？

Pipeline 让客户端连续发送多条命令，再集中读取响应，减少逐条等待网络往返的时间与调用开销。它是传输与调用优化，不会把多条命令自动变成事务，也不保证整个批次不被其他客户端穿插。

一百次 GET 为什么可以更快？#

逐条发送时，每次都要等上一条返回后再发下一条。若网络 RTT 为 2 毫秒，忽略其他成本的一百次串行访问仅往返等待就约 200 毫秒。Pipeline 把多次等待重叠起来，Redis 仍执行一百条命令，但不必为每条都单独等待一次往返。这是示意估算，实际还受带宽、排队和客户端实现影响。

Pipeline 并不会天然减少命令数量。相同语义下，MGET、MSET 等原生批量命令有时更合适；Cluster 场景需满足槽位规则，或由客户端按节点拆分。若后一个操作依赖前一个响应，不能简单把逻辑直接打包，需要分阶段，或将条件判断放进短 Lua 脚本。

Redis 与客户端需要缓存请求和响应，超大批次会增加内存、尾延迟及连接独占时间。一个包含大 Value 的批次也会消耗大量网络带宽。应按命令数量、响应总字节量和超时目标设上限，而不是只追求吞吐数字。

一般仍按收到的命令处理，各命令有各自响应；客户端要逐条检查错误，不能只看批次是否成功返回。

结果可能不确定，部分命令已经执行。对于 INCR 等非幂等操作，直接重发可能重复生效，需要业务幂等或确认机制。

它不改变 Redis 6/7 核心命令的常见串行执行模型；多个 Cluster 节点可各自处理分片，但那来自分片架构。

低延迟单请求、强依赖链、巨大响应和实例内存紧张时，应采用小批次或其他合适方案，避免影响其他请求。