在批量读写Redis的场景里，最直观的写法是循环调用get或set，比如要刷新一万条缓存，就写一个for循环逐条更新。这种代码功能上没问题，但性能往往惨不忍睹：本机测试可能还好，一旦应用到跨机房部署的线上环境，一次批量操作跑十几秒都很常见。瓶颈其实不在Redis本身，而在网络往返上。Pipeline管道机制就是为解决这个问题而生的，它能把上万条命令的执行时间压缩到原来的几分之一甚至几十分之一。
先搞清楚：时间到底花在哪里
一条Redis命令的耗时大致由三部分组成：客户端发送命令的网络传输时间、服务端执行命令的时间、响应返回客户端的网络传输时间。其中服务端执行一条简单命令（如get、set）通常只需要微秒级别，非常快，而一次网络往返（RTT）在局域网环境下通常是零点几毫秒，跨机房则可能达到几毫秒甚至更高。
假设一次RTT是1毫秒，执行1万条命令逐条发送，光网络等待就要10秒左右，而服务端真正执行这1万条命令的总耗时可能只有10毫秒。也就是说，99%以上的时间都浪费在了等待网络往返上。这就是为什么逐条执行慢的原因——Redis本身不慢，是通信方式拖了后腿。
Pipeline的原理很直接：客户端把一批命令先在本地缓冲起来，一次性打包发送给服务端，服务端依次执行后把所有结果一次性返回。这样1万条命令只需要一次网络往返（或少数几次），网络开销从N次降为1次，整体耗时基本就接近服务端的纯执行时间了。
Pipeline、mget和事务的区别
很多人容易把Pipeline和mget、mset这类批量命令搞混，也容易把它和MULTI/EXEC事务混为一谈，这里有必要厘清一下。
mget、mset是服务端原生支持的批量命令，一次命令操作多个key，性能最优。但它们只支持特定的命令类型，场景有限，而且操作的所有key必须落在同一个槽（集群模式下），灵活性不足。Pipeline则对命令类型没有限制，你可以把get、set、expire、del等各种命令混在一起打包，通用性强得多。两者还可以结合使用，比如用Pipeline分批发送mget命令，既减少了RTT又利用了批量命令的高效。
事务和Pipeline是两个维度的东西。MULTI/EXEC保证命令的顺序执行和隔离性，中间不会插入其他客户端的命令；Pipeline只负责批量传输，不提供任何原子性保证，服务端执行管道里的命令时，其他客户端的命令是可能穿插执行的。另外，pipeline在服务端会维护一个队列缓存所有还没执行的命令和响应，所以单次打包的命令数量要控制，不能无限大。
代码实战：不同客户端下的Pipeline用法
先看最经典的Jedis，用法是通过Pipeline对象把命令入队，最后sync()统一发送并获取结果。
Jedis jedis = new Jedis("127.0.0.1", 6379);
Pipeline pipe = jedis.pipelined();
// 分批打包，每批1000条，避免单次包过大
int batchSize = 1000;
int count = 0;
for (String key : keyList) {
pipe.setex("cache:" + key, 3600, "value");
count++;
if (count % batchSize == 0) {
// 同步执行当前批次并清空缓冲区
pipe.sync();
}
}
// 处理剩余不足一批的命令
pipe.sync();
jedis.close();
如果用的是Spring Boot默认的Lettuce客户端，写法更简洁，借助executePipelined回调即可，而且Lettuce基于Netty，底层天然支持异步流水线。
List<Object> results = stringRedisTemplate.executePipelined(new RedisCallback<Object>() {
@Override
public Object doInRedis(RedisConnection connection) {
for (String key : keyList) {
byte[] k = ("cache:" + key).getBytes();
// 只入队，不等待返回
connection.stringCommands().setEx(k, 3600, "value".getBytes());
}
return null;
}
});
// results中按入队顺序存放每条命令的执行结果
排查问题时也可以直接用redis-cli验证效果，加上--pipe参数即可从标准输入批量灌入命令。
# 生成命令流并通过管道灌入redis cat commands.txt | redis-cli --pipe # commands.txt内容形如： # SET key1 value1 # SET key2 value2 # 每条命令需以协议要求的格式结尾，redis-cli会自动处理
使用Pipeline的几个实践建议
第一，一定要分批。单次pipeline不建议超过几千条命令，命令太多会占用服务端大量内存缓存请求和响应，还可能造成Redis短暂阻塞其他客户端。常见的做法是每500到1000条sync一次，兼顾性能和稳定性。
第二，注意超时设置。打包后单次请求的数据量和执行时间都变大了，客户端读写超时如果还按单条命令的标准设置，容易出现超时误判，建议根据批量大小适当调大超时时间。
第三，集群模式下的坑。Redis Cluster下使用Pipeline要求打包的所有key必须落在同一个节点上，否则会报错。通用做法是用hash tag强制一批key落在同一槽，比如用{user1001}:profile和{user1001}:orders这种写法，花括号内的内容相同则槽相同。业务上通常按用户或分片维度来组织批量操作。
第四，结果要按顺序消费。Pipeline返回的结果列表与命令入队顺序一一对应，拿到结果后按索引取值即可。但要留意，即使其中某条命令出错，管道也不会中断，错误信息会体现在对应位置的结果里，所以关键业务最好逐条校验返回值，别默认全部成功。
总结一下，Pipeline的本质是用一次网络往返替代N次，把批量操作的性能瓶颈从网络转移回服务端的纯计算能力上。在缓存批量预热、批量查询、批量删除这类场景里，它几乎是零成本接入又收益明显的优化手段，配合分批控制和集群hash tag，可以放心地用在高并发生产环境中。
Redis Pipeline批量操作性能优化修改时间：2026-09-15 16:36:37