Pipeline
-
Pipeline
Redis客户端执行一条命令分为如下四个过程：
1）发送命令
2）命令排序
3）命令执行
4）返回结果其中1）+4）称为Round Trip Time（RTT，往返时间）。
Redis提供了批量操作命令（例如mget、mset等），有效地节约RTT。但大部分
命令是不支持批量操作的，例如要执行n次hgetall命令，并没有mhgetall命令
存在，需要消耗n次RTT。Redis的客户端和服务端可能部署在不同的机器上。例
如客户端在北京，Redis服务端在上海，两地直线距离约为1300公里，那么1次
RTT时间=13002/(3000002/3)=13毫秒（光在真空中传输速度为每秒30秒公
里，这里假设光纤为光速的2/3），那么客户端在1秒内大约只能执行80次左右
的命令，这个和Redis的高并发高吞吐特性背道而驰。Pipeline（流水线）机制能改善上面这类问题，它能将一组Redis命令进行组
装，通过一次RTT传输给Redis，再将这组Redis命令的执行结果按顺序返回给客
户端。Pipeline并不是什么新的技术活机制，很多技术上都使用过。而且RTT在不同网
络环境下会有不同，例如同机房和同机器会比较快，跨机房跨地区会比较慢。
Redis命令真正执行的时间通常在微秒级别，所以才会有Redis性能瓶颈是网络
这样的说法。redis-cli的--pipe选项实际上就是使用Pipeline机制，例如下面操作将set
hello world和incr counter两条命令组装：echo -en '*3\r\n$3\r\nSET\r\n5\r\nhello\r\n$5\r\nworld\r\n*2\r\n$4\r\nincr\r\n$7\r\ncounter\r\n' | redis-cli --pipe但大部分开发人员更倾向于使用高级语言客户端中的Pipeline，目前大部分
Redis客户端都支持Pipeline -
性能测试
网络 延迟 非Pipeline Pipeline 本机 0.17ms 573ms 134ms 内网服务器 0.41ms 1610ms 240ms 异地机房 7ms 78499ms 1104ms 上表给出了在不同网络环境下非Pipeline和Pipeline执行10000次set操作的
效果，可以得到如下两个结论：- Pipeline执行速度一般比逐条执行要快。
- 客户端和服务端的网络延时越大，Pipeline的效果越明显。
-
原生批量命令与Pipeline对比
可以使用Pipeline模拟出批量操作的效果，但是在使用时要注意它与原生批量
命令的区别，具体包含以下几点：- 原生批量命令是原子的，Pipeline是非原子的。
- 原生批量命令是一个命令对应多个key，Pipeline支持多个命令。
- 原生批量命令是Redis服务端支持实现的，而Pipeline需要服务端和客户端
的共同实现。
-
最佳实践
Pipeline虽然好用，但是每次Pipeline组装的命令个数不能没有节制，否则一
次组装Pipeline数据量过大，一方面会增加客户端的等待时间，另一方面会造
成一定的网络阻塞，可以将一次包含大量命令的Pipeline拆分成多次较小的
Pipeline来完成。Pipeline只能操作一个Redis实例，但是即使在分布式Redis场景中，也可以作
为批量操作的重要优化手段。
