pipeline解决Redis频繁命令往返导致的性能瓶颈

发表于2026-04-09|更新于2026-04-09|后端

|浏览量:

客户端和服务端交互模型

Redis 的 pipeline 交互模型

Redis pipeline 与原生批量mset等等命令对比

原生批量命令是原子性，pipeline 是非原子性的
原生批量命令一次只能执行一种命令，pipeline 支持批量执行不同命令
原生批命令是服务端实现，而 pipeline 需要服务端与客户端共同完成

需要注意：

Redlis 事务是具有隔离性的，在执行过程中不会穿插执行其他客户瑞发送的命令
使用 pipeline 组装的命令个数不能太多，不然数据量过大
pipeline 会按照指令缓冲的顺序执行，但是可能会穿插其他客户端发送来的命令，即时序性不一定能够保证
pipeline 执行中间某一个指令出现异常，将会继续执行后续的指令，即不能保证原子性

文章作者: 褚成志

文章链接: https://www.chucz.asia/2026/04/09/pipeline%E8%A7%A3%E5%86%B3Redis%E9%A2%91%E7%B9%81%E5%91%BD%E4%BB%A4%E5%BE%80%E8%BF%94%E5%AF%BC%E8%87%B4%E7%9A%84%E6%80%A7%E8%83%BD%E7%93%B6%E9%A2%88/

版权声明: 本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源褚成志的分享站！

性能优化 Redis

相关推荐

分布式锁最佳实践

在单体的应用开发场景中涉及并发同步的时候，大家往往采用 Synchronized（同步）或者同一个JVM内Lock机制来解决多线程间的同步问题。在分布式集群工作的开发场景中，就需要一种更加高级的锁机制来处理跨机器的进程之间的数据同步问题，这种跨机器的锁就是分布式锁。超卖问题复现现象存在如下的几张表：商品表订单表订单item表 :::danger 商品的库存为1，但是并发高的时候有多笔订单。 ::: 错误案例一：数据库 update 相互覆盖直接在内存中判断是否有库存，计算扣减之后的值更新数据库，并发的情况下会导致相互覆盖发生： 123456789101112131415161718192021222324252627@Transactional(rollbackFor = Exception.class)public Long createOrder() throws Exception { Product product = productMapper.selectByPrimaryKey(purchaseProductId); ...

Redis不同数据类型代码场景实践

string博客不好的实现12345jedis.set("key1", "value1");jedis.get("key1");jedis.del("lock_test");jedis.incr("blog_id_counter");Long key = jedis.incrBy("key", 1); 1jedis.set("lock_test", "value_test", SetParams.setParams().nx()); 12345678Long publishBlogResult = jedis.msetnx("article:1:title", "学习Redis", "article:1:content", "如何学好redis的使用", "art...

CPU分析和优化总结

CPU 性能指标CPU 使用率用户 CPU 使用率，包括**用户态 CPU 使用率（user）和低优先级用户态 CPU 使用率（nice），表示 CPU 在用户态运行的时间百分比。用户 CPU 使用率高，通常说明有应用程序比较繁忙。** 系统 CPU 使用率，表示 CPU 在内核态运行的时间百分比（不包括中断）。系统 CPU 使用率高，说明内核比较繁忙。等待 I/O 的 CPU 使用率，通常也称为 iowait，表示等待 I/O 的时间百分比。iowait 高，通常说明系统与硬件设备的 I/O 交互时间比较长。软中断和硬中断的 CPU 使用率，分别表示内核调用软中断处理程序、硬中断处理程序的时间百分比。它们的使用率高，通常说明系统**发生了大量的中断**。除了上面这些，还有在虚拟化环境中会用到的窃取 CPU 使用率（steal）和客户 CPU 使用率（guest），分别表示被其他虚拟机占用的 CPU 时间百分比，和运行客户虚拟机的 CPU 时间百分比。平均负载（Load Average），系统的平均活跃进程分别指过去 1 分钟...

Redis实现分布式锁以及Redis客户端比较

若锁存在，且唯一标识匹配：则先将锁重入计数减1local counter = redis.call(‘hincrby’, KEYS[1], ARGV[3], -1);if (counter > 0) then – 锁重入计数减1后还大于0：表明当前线程持有的锁还有重入，不能进行锁删除操作，但可以友好地帮忙设置下过期时期 redis.call(‘pexpire’, KEYS[1], ARGV[2]); return 0;else – 锁重入计数已为0：间接表明锁已释放了。直接删除掉锁，并广播解锁消息，去唤醒那些争抢过锁但还处于阻塞中的线程 redis.call(‘del’, KEYS[1]); redis.call(‘publish’, KEYS[2], ARGV[1]); return 1;end; return nil; 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455...

对比 AOF 文件的内容是操作命令； RDB 文件的内容是二进制数据。 RDB 快照就是记录某一个瞬间的内存实际数据，而 AOF 文件记录的是命令操作的日志 RDB 恢复数据的效率会比 AOF 高些，因为直接将 RDB 文件读入内存就可以，不需要像 AOF 那样还需要额外执行操作命令的步骤才能恢复数据。 RDB 丢失的数据会更多，因为保存是全量快照，所以频率不能太高否则性能不好，所以会丢失更多数据 AOF 怎么用12345678910111213141516171819// redis.confappendonly yesappendfilename "appendonly.aof"# 同步方式appendfsync everysec# aof重写期间是否同步no-appendfsync-on-rewrite no# 重写触发配置auto-aof-rewrite-percentage 100auto-aof-rewrite-min-size 64mb# 加载aof时如果有错如何处理aof-load-truncated yes # yes表示如果aof尾部文件...

数据加载中