我要评论一、明明按顺序发的命令，为什么redis里的数据顺序乱了？
上周四凌晨，我们的实时风控系统突然告警——用户行为事件的时间戳出现乱序，导致风控规则误判。
这个系统每秒处理约2万条事件，采用redis pipeline批量写入以降低网络开销。
问题来了：
代码里明明按时间顺序将事件推入pipeline，但redis里却出现了时间戳倒序的数据。 你是不是也认为pipeline只是"批量发送命令"？
我也曾这么想，直到这次踩坑。
二、现象复现：pipeline的"伪顺序保证"
先看当时的错误代码（python示例，其他语言同理）：
pipe = redis.pipeline()
for event in sorted_events: # 假设已按时间戳升序排序
pipe.zadd("user_events", {event.id: event.timestamp}) # 写入有序集合
pipe.execute()
理论上，sorted_events是按时间升序排列的，写入redis后zrange user_events 0 -1应该得到有序结果。
但实际观测到部分数据乱序，例如：
实际存储: [事件a(ts=100), 事件c(ts=300), 事件b(ts=200)]
- 关键现象：乱序并非完全随机，而是局部乱序（比如95%有序，5%乱序），这让问题更难定位。
三、根因：tcp/ip栈与redis线程模型的合谋
1. 网络层乱序
尽管客户端通过单个tcp连接顺序发送命令，但tcp/ip协议栈可能存在：
- nagle算法延迟发送小包
- 网络丢包重传导致乱序到达
- 内核缓冲区处理延迟
2. redis服务端线程竞争
即使命令按序到达redis：
- io线程将命令放入队列时存在竞争
- 工作线程从队列取命令时可能乱序（尤其在高负载时）
- 3. pipeline的批量特性放大问题
与单条命令不同，pipeline将多个命令作为一个"批处理单元"提交。
如果其中某个命令执行较慢（例如遇到大key），可能导致后续命令先被执行完成。
四、解决方案：用watch+multi实现真·原子顺序
正确写法需要满足两个条件：
- 客户端确保命令按序到达redis服务端
- redis服务端确保命令按序执行
with redis.pipeline() as pipe:
while true:
try:
pipe.watch("user_events") # 监视key
pipe.multi() # 开启事务
for event in sorted_events:
pipe.zadd("user_events", {event.id: event.timestamp})
pipe.execute() # 原子化执行
break
except watcherror:
continue # 冲突则重试
实测对比（10万条数据，单位：ms）：
| 方案 | 耗时 | 乱序率 |
|---|---|---|
| 纯pipeline | 1200 | 0.7% |
| watch+multi | 1800 | 0% |
| 单条命令 | 9500 | 0% |
五、避坑清单：pipeline使用的3条军规
关键区别：
watch确保执行期间没有其他写入干扰multi将pipeline内的命令作为原子操作按序执行
顺序敏感场景慎用纯pipeline
监控pipeline的乱序率
- 计数器递增、时间序列数据写入等场景需要额外保障
- 可改用lua脚本或watch/multi
# 通过redis慢查询日志观察命令执行顺序 slowlog-log-slower-than 10000 slowlog-max-len 1000
区分"网络批量化"和"原子性"
六、最后的选择：什么时候该用pipeline？
经过这次教训，我的决策树变成：
允许最终一致：用纯pipeline（性能最优）
- pipeline只解决网络往返问题
- 原子性和顺序性需要事务/lua脚本配合
如果
需要强顺序：watch+multi+pipeline（性能折衷）
如果
需要强原子性：lua脚本（功能最稳）
七、总结
以上为个人经验，希望能给大家一个参考，也希望大家多多支持代码网。
发表评论