管道

Redis 管道 (Pipeline) 这个技术本质上是由客户端提供的，跟服务器没有什么直接的关系。

Redis 的消息交互

当使用客户端对 Redis 进行一次操作时，客户端将请求传送给服务器，服务器处理完毕后，再将响应回复给客户端。这要花费一个网络数据包来回的时间。

如果连续执行多条指令，那就会花费多个网络数据包来回的时间。

管道操作的本质，服务器根本没有任何区别对待，还是收到一条消息，执行一条消息，回复一条消息的正常的流程。客户端通过对管道中的指令列表改变读写顺序，合并 write 和 read 操作，就可以大幅节省 IO 时间。

打包的命令越多，缓存消耗内存也越多。所以并不是打包的命令越多越好。

pipeline 中发送的每个 command 都会被 server立即执行，如果执行失败，将会在此后的响应中得到信息；也就是 pipeline 并不是表达“所有 command 都一起成功”的语义，管道中前面命令失败，后面命令不会有影响，继续执行。也就是说管道不具备原子性。

管道压力测试

Redis 自带了一个压力测试工具 redis-benchmark，使用这个工具就可以进行管道测试。

首先我们对一个普通的 set 指令进行压测，QPS 大约 5w/s。

> redis-benchmark -t set -q
SET: 51975.05 requests per second

加入管道选项 -P 参数，它表示单个管道内并行的请求数量，看下面 P=2，QPS 达到了 9w/s。

> redis-benchmark -t set -P 2 -q
SET: 91240.88 requests per second

再看看 P=3，QPS 达到了 10w/s。

> redis-benchmark -t set -P 3 -q
SET: 102354.15 requests per second

但如果再继续提升 P 参数，发现 QPS 已经上不去了。因为这里 CPU 处理能力已经达到了瓶颈，无法再继续提升了。