一、Pipeline概述

• Redis客户端执行一条命令分为如下四个过程：
  • 1.发送命令
  • 2.命令排队
  • 3.命令执行
  • 4.返回结果
• 其中1+4称为Round Trip Time（RTT，往返时间）

Pipeline概述

• Redis提供了批量操作命令（例如mget、mset等），有效地节约RTT。但大部分命令是不支持批量操作的，例如要执行n次hgetall命令，并没有 mhgetall命令存在，需要消耗n次RTT。Redis的客户端和服务端可能部署在不 同的机器上。例如客户端在北京，Redis服务端在上海，两地直线距离约为 1300公里，那么1次RTT时间=1300×2/（300000×2/3）=13毫秒（光在真空中 传输速度为每秒30万公里，这里假设光纤为光速的2/3），那么客户端在1秒内大约只能执行80次左右的命令，这个和Redis的高并发高吞吐特性背道而 驰
• Pipeline（流水线）机制能改善上面这类问题，它能将一组Redis命令进行组装，通过一次RTT传输给Redis，再将这组Redis命令的执行结果按顺序返回给客户端
• 下图为没有使用Pipeline执行了n条命令，整个过程需要n次 RTT

• 下图为使用Pipeline执行了n次命令，整个过程需要1次RTT

二、性能测试

• 下图给出了在不同网络环境下非Pipeline和Pipeline执行10000次set操作的效果，可以得到如下两个结论：
  • Pipeline执行速度一般比逐条执行要快
  • 客户端和服务端的网络延时越大，Pipeline的效果越明显

• 备注：因测试环境不同可能得到的具体数字不尽相同，本测试Pipeline每次携带100条命令

三、原生批量命令与Pipeline对比

• 可以使用Pipeline模拟出批量操作的效果，但是在使用时要注意它与原生批量命令的区别，具体包含以下几点：
  • 原生批量命令是原子的，Pipeline是非原子的
  • 原生批量命令是一个命令对应多个key，Pipeline支持多个命令
  • 原生批量命令是Redis服务端支持实现的，而Pipeline需要服务端和客户端的共同实现

四、最佳实践

• Pipeline虽然好用，但是每次Pipeline组装的命令个数不能没有节制，否则一次组装Pipeline数据量过大，一方面会增加客户端的等待时间，另一方 面会造成一定的网络阻塞，可以将一次包含大量命令的Pipeline拆分成多次 较小的Pipeline来完成
• Pipeline只能操作一个Redis实例，但是即使在分布式Redis场景中，也可以作为批量操作的重要优化手段，具体见后面“缓存设计”文章的介绍