首先很多人对redis的管道pipline有个误解，认为这是redis server提供的高级特性，其实这和redis server没任何关系，pipline是redis client的功能。pipline出现的原因是，因为redis客户端和服务器每次执行一个命令都要有一个网络请求来回，命令多了这种网络消耗就很可观了。如果可以一次网络请求而执行多条命令，是不是就可以节省很多网络传输时间呢？pipline在这种需求下出现了。
对于redis 服务端来说，并没有不同。依然是接受一条请求，处理一条请求。
通过使用管道可以大幅增加redis的处理能力
Redis 自带了一个压力测试工具redis-benchmark，使用这个工具就可以进行管道测试。
不使用管道
可处理set 7.5W/s
通过管道-P 2 设置每次2个命令
性能提高到15W/s.线性增长一倍
可以看到，我这台机器上，基本在40左右，性能达到顶峰。之后再增加一个管道中的命令数量也不会增加性能。
因为这里 CPU 处理能力已经达到了瓶颈，Redis 的单线程 CPU 已经飙到了 100%，所以无法再继续提升了。
个人理解是这样：pipeline通过减少客户端与redis的通信次数来实现降低往返延时时间，而且Pipeline 实现的原理是队列，就是说可以把多条指令放入到一个tcp报文一起发送，server则可以将三条命令的处理结果放到一个tcp报文返回。
有些系统可能对可靠性要求很高，每次操作都需要立马知道这次操作是否成功，是否数据已经写进redis了，那这种场景就不适合。
还有的系统，可能是批量的将数据写入redis，允许一定比例的写入失败，那么这种场景就可以使用了，比如10000条一下进入redis，可能失败了2条无所谓，后期有补偿机制就行了，比如短信群发这种场景，如果一下群发10000条，按照第一种模式去实现，那这个请求过来，要很久才能给客户端响应，这个延迟就太长了，如果客户端请求设置了超时时间5秒，那肯定就抛出异常了，而且本身群发短信要求实时性也没那么高，这时候用pipeline最好了。
閱讀更多 IT技術圈 的文章
