Redis 性能显微镜
少等几次，不是一起成功
Pipeline 把多条命令集中发送，省掉的是一次次网络往返。命令仍会逐条执行、逐条返回，也仍可能被其他客户端的命令穿插。
同一批命令，两种时间线
网络等待
Redis 执行
批次往返
逐条请求：发一条，等一次24 RTT
0 ms292.8 ms
每条命令后都卡着一次 RTT；远端网络越慢，空等的黄色部分越显眼。
Pipeline：凑成一批，再等一次3 RTT
0 ms40.8 ms
命令执行时间没有消失；被压缩的是往返次数。批次太大还会增加响应体积与排队延迟。
逐条 ≈ 命令数 × (RTT + 单命令服务时间)
VS
Pipeline ≈ 批次数 × RTT + 命令数 × 单命令服务时间
批量发送 ≠ 原子执行
下方顺序展示 Redis 可能实际看到的命令边界。
客户端 A
SET a 1INCR nBAD xGET nSET b 2
客户端 B
——DEL n——
A:SET→A:INCR→B:DEL→A:ERR→A:GET→A:SET
B 的命令穿插进 A 的 Pipeline；A 的错误响应不会抹掉前后命令。
Pipeline 管网络，不管事务。
需要命令不被穿插，应考虑 MULTI/EXEC 或 Lua；需要失败后撤销，Redis 事务也不提供关系型数据库那样的自动回滚。
现场判断
把性能收益和正确性保证拆开看。
一个 Pipeline 中第 3 条命令类型错误，最准确的描述是哪一个？
选择一个答案，再用上面的命令边界验证判断。