3.3.1 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时间=1300×2/（300000×2/3）=13毫秒（光在真空中传输速度为每秒30万公里，这里假设光纤为光速的2/3），那么客户端在1秒内大约只能执行80次左右的命令，这个和Redis的高并发高吞吐特性背道而驰。
Pipeline（流水线）机制能改善上面这类问题，它能将一组Redis命令进行组装，通过一次RTT传输给Redis，再将这组Redis命令的执行结果按顺序返回给客户端。
Pipeline并不是什么新的技术或机制，很多技术上都使用过。而且RTT在不同网络环境下会有不同，例如同机房和同机器会比较快，跨机房跨地区会比较慢。Redis命令真正执行的时间通常在微秒级别，所以才会有Redis性能瓶颈是网络这样的说法。
3.3.2 性能测试
下面我在本地环境和云环境下执行非Pipeline和Pipeline执行1万次set操作的效果，先丢出结果。
| 网络 | 延迟 | 非Pipeline | Pipeline |
|---|---|---|---|
| 本机 | 0.15ms | 617ms | 36ms |
| 内网到腾讯云 | 40.71ms | 417770ms | 338ms |
这里可以看出我在自己测试内网到腾讯云的时候，用Pipeline的效率高很多倍的。多出来的时间几乎就是40.71ms*10000=407100ms。
在本机测试的时候我们也可以得出Pipeline执行命令的效率要比非Pipeline效率高的结论。
下面是测试方法：
- 生成测试数据
用shell脚本生成一个一万行txt文档，里面的内容为：
set test_key1 test_values1
set test_key2 test_values2
set test_key3 test_values3
.....
- 分别在本地和非本地测试Pipeline
#非本地Pipeline
time cat test_redis.txt| redis-cli -a redis123 -h 94.1xx.xxx.xxx -p 29001 --pipe
#非本地非Pipeline
time cat test_redis.txt| redis-cli -a redis123 -h 94.1xx.xxx.xxx -p 29001 >/dev/null
注意：因为我的Redis是安装在腾讯服务器上的，直接把redis暴露到公网上是很危险的，这里我修改了几个参数.
bind 0.0.0.0
port 29001
requirepass redis123
3.3.3 原生批量命令与Pipeline对比
可以使用Pipeline模拟出批量操作的效果，但是在使用时要注意它与原生批量命令的区别，具体包含以下几点：
- 原生批量命令是原子的，Pipeline是非原子的。
- 原生批量命令是一个命令对应多个key，Pipeline支持多个命令。
- 原生批量命令是Redis服务端支持实现的，而Pipeline需要服务端和客户端的共同实现。
3.3.4 最佳实践
Pipeline虽然好用，但是每次Pipeline组装的命令个数不能没有节制，否则一次组装Pipeline数据量过大，一方面会增加客户端的等待时间，另一方面会造成一定的网络阻塞，可以将一次包含大量命令的Pipeline拆分成多次较小的Pipeline来完成。
Pipeline只能操作一个Redis实例，但是即使在分布式Redis场景中，也可以作为批量操作的重要优化手段，具体细节见第11章。
网友评论