Redis pipeline 批量命令为什么不是事务

Redis pipeline 把多条命令一次写入连接，主要目的是减少客户端与 Redis 之间的往返等待。它不会自动执行 MULTI，也不会因为其中一条命令失败就撤销前面已经成功的命令，所以“批量发送”不等于“事务”。

pipeline 批量命令为什么不是事务

Redis 的请求响应协议通常是“发一条、等一次回复”。命令数量一多，耗时就会被 RTT 和系统调用放大。pipeline 允许客户端先连续发送多条命令，再集中读取回复，Redis 仍按收到的命令逐条处理，只是客户端不必在每条命令之间等待。

因此 pipeline 没有下面这些事务语义：不会把命令排他地包起来，不会检查所有命令是否都成功，也没有失败后的回滚日志。批次很大时还要分段，因为服务器需要暂存尚未读走的回复。

Redis 的 pipeline 批量命令本质是客户端把多条指令打包后一次性发给服务端执行，全程没有提前校验指令合法性、没有服务端级别的执行兜底互斥机制，执行过程中某条命令报错或者崩溃，后续已经发出去的命令仍然会继续执行，不会自动回滚前面已经生效的操作，完全不满足事务的原子性、隔离性核心约束，所以它本身不属于事务实现，只是用来减少网络往返开销的批量传输优化手段。

pipeline 只是网络层面的批量打包优化，没有原子性兜底，不提供事务的执行保证，和 Redis 原生 MULTI/EXEC 事务是完全不同的实现逻辑。

需要隔离执行时使用 MULTI/EXEC

如果目标是让一组命令连续执行，应显式使用 MULTI 和 EXEC。进入 MULTI 后，后续命令先进入队列，调用 EXEC 才真正执行；执行期间其他客户端不会插入这组命令。

# redis-cli 会话示意：MULTI/EXEC 才是事务边界
MULTI
SET inventory:book 9
INCR sales:book
EXEC

客户端通常会收到按原顺序排列的回复。若需要“读到的值没有被别人改过才提交”，在读取前执行 WATCH key，一旦监视键在 EXEC 前发生变化，事务会被放弃，客户端应重新读取并重试。

命令报错时为什么还可能留下部分结果

Redis 事务强调连续执行，不等同于数据库式回滚。命令在入队阶段就发现语法或参数错误时，事务可能被拒绝；但命令执行阶段出现类型错误时，其他已经排队的命令仍会继续执行。例如对字符串执行列表操作，返回 WRONGTYPE，并不会撤销同一批中此前成功的 SET。

这也是 pipeline 最容易被误判的地方：pipeline 返回多条结果，调用方必须逐项检查；MULTI/EXEC 也要检查 EXEC 返回数组和 WATCH 冲突，而不能只看网络请求是否成功。

读—计算—写场景怎么选方案

实践中两者也可以组合：把多个彼此独立的 EVAL 或普通命令放进 pipeline，以减少网络等待；但 pipeline 只改变发送方式，脚本或事务本身才决定一组逻辑的原子性。排查时先问“我要降低 RTT，还是要保证一致性”，通常就不会选错。

常见问题

pipeline 中前一条命令失败，后一条会自动跳过吗？

不会。Redis 会返回各条命令的结果，客户端需要自己判断并决定补偿或重试。

MULTI/EXEC 能像 MySQL 一样回滚吗？

不能。它提供队列、连续执行和可选的乐观锁，不提供通用自动回滚。

什么时候只用单条命令就够了？

如果需求能由 INCR、SET NX 等单条原子命令表达，优先用单条命令，代码和失败处理都更简单。