Redis 命令 · 边界实验

三条轨道,
三种完全不同的保证

把一个业务包裹投进执行轨道,盯住客户端、网络和 Redis 工作台之间发生了什么。少一次往返,不等于多一份原子性;不被插队,也不等于出错会回滚。

一、领取业务包裹

点击选择,或把包裹拖进下面任意轨道。每个场景都能跑三次,真正有意义的是比较差异。

二、送入执行闸门

已领取:批量写日志。现在选择一条轨道。

CLIENT → NETWORK → REDIS 服务端工作台在线
批量写日志 × Pipeline 观察一次批量发送如何节省往返

Pipeline:省在路上

客户端不等上一条回复就继续发送。服务器仍逐条处理,其他客户端的命令可能穿插。它不是事务,也不提供原子性。

事务:关上执行闸门

MULTI 后命令先入队,EXEC 后连续执行且不会被其他客户端插队。但运行期某条命令报错,前面已经成功的命令不会自动回滚

Lua:短工单进工作台

脚本执行期间不被其他命令插入,适合短小的“读—判—写”。脚本一旦慢循环,单线程执行路径会被占住,其他请求也只能排队。

三、轮到你放行

别按“听起来最强”来选,按业务真正需要的保证来选。

现场判断

秒杀扣库存:必须在同一执行边界内读取库存、判断大于 0,再减 1。逻辑很短,且希望一次请求完成。

哪个方案最贴合?