Redis消息交互HI ！我是小小，我们来到了这期-深入探讨Redis管道。
当我们使用客户端对Redis进行一次操作时，客户端会把请求传送给服务器，服务器处理完成以后，再把响应恢复给客户端，这要花费一个网络数据包的来回时间。
如果要连续执行多条指令，那就会花费多个网络数据包来回的时间，如图所示
回到客户端代码里，客户端经历了写-读-写-读四个操作完整的执行了两条指令。
writer -> read -> write -> read
现在如果我们调整读写顺序，改成写 - 写 - 读 - 读 这两个指令同样可以正常完成。如图所示
write -> write -> read -> read
两个连续的写操作和两个联系的读操作总共只会花费一次网络来回，就好像连续的写操作合并了，连续的读操作也合并了、如图所示
这便是管道的本质，服务器根本没有任何区别对待，还是走着收到一条消息，执行一条消息，回复一条消息的正常流程，客户端通过对管道中的指令列表改变读写顺序就可以大幅的节省IO时间，管道中的指令越多，效果越好。
Redis自带了一个压力测试工具，redis-benchmark使用这个工具，可以对管道进行测试。首先对一个set指令进行压力测试
> 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参数，会发现已经提升不起来了。原因：因为在这里，CPU参数已经达到了瓶颈，Redis单线程CPU消耗已经达到了100%，无法继续飙升了。
深入理解管道本质如图所示，是一个完整的交互流程图
用文字描述一段流程
- 客户端进程调用write 把消息写到操作系统内核为套接字分配的发送缓冲send buffer 中
- 客户端操作系统内核把发送缓冲的内容发送到网卡，网卡硬件把数据通过网际路由送到服务器的网卡。
- 服务器操作系统内核把网卡的数据放到内核为套接字分配的接受缓冲recvbuffer 中。
- 服务器进程调用read从接收缓冲中取出消息进行处理。
- 服务器进程调用write把响应消息写入到内核为套接字分配的发送缓冲send buffer中。
- 服务器操作系统内核把要发送的缓冲的内容发送到网卡，网卡硬件把数据通过网际路由送到客户端的网卡。
- 客户端操作系统内核把万科数据放入到内核，为套接字分配的接收缓冲recvbuffer中。
- 客户端进程调用read从接收缓冲中取出消息返回给上层业务逻辑处理。
- 结束。
我是小小，一个生于二线，活在一线的佛系程序猿，你若不在，我将永远都在，我在人间彷徨着，寻找着未来，我就是我，我是小小，我们下期再见。
