多图解析，让Redis提高数倍性能的Redis管道，是这么一回事

曾经有个阿里P9大佬说过，对于后台开发来说，能够把Spring跟Redis的吃透，来阿里工作完全可以胜任绝大部分后端开发的工作。Redis，作为当前最流行的后台缓存/存储组件，被广泛应用在不同行业、不同系统、不同服务中。今天，我们来谈一谈一个Redis的高级用法，如何使用Redis-cli的管道功能。在了解Redis的管道功能之前，我们先来了解下Linux系统的底层知识，Socket是如何进行通信的。很多JAVA程序员同学，总是觉得Linux的底层知识没什么用，相信你看完这个Redis-client管道的知识点之后，能够改变自己的一些想法。

计算机A与计算机B的通信过程是这样的，计算机A将要发送的数据写到自己的发送缓冲区里面SendBuffer，Linux操作系统内核会自己把这部分数据，按照设定的协议，通过网关，把数据发送到复杂地计算机网络中。计算机B的内核会接收到这部分信息，并且会把数据拷贝到接受缓冲区，RecvBuffer，然后B机器的进程过来Read就能获取到数据，这里就存在这样一种情况，如果Read的时候数据还没有到B机器或者还没拷贝到缓冲区，那么就会阻塞。很明显，如果我们在一次业务查询中有多次请求，那么，我们希望服务器只要从缓冲区里面读取一次数据，那么就能节省一定量的时间，这是一方面。从另一方面进行考虑，假如我们在一个业务请求中，需要从Redis上获取3个不同的数据，如果我们一次一次的获取，那会怎么样？

这种请求模型有两个明显的缺点：

每次查询，都有网络上的延迟。特别是如果Redis跟系统服务不在同一个机房，单趟来回可能要10ms，多了两趟来回，就要多20ms。对于一个请求，里面需要处理20ms，对于整个请求来说，可能延迟就不止增加20ms了，毕竟服务器是多线程的，可能中途又被Linux操作系统切出去干其他事情，整个系统的并发跟吞吐立马就降下来了。面对这种情况，我们会想，如果我们能够把三次请求合并成一次丢给服务器，服务器再一次性返回给我们，这不就解决问题了么？这便是Redis的管道！

对于Redis来说，还是需要进行3次子查询，但是对于整个系统来说，网络通信的次数明显就减少了，并发自然就上去了，吞吐自然也上去了。

我们使用Redis的benchmark工具看到，-P的意思就是把多个请求放到一个管道中，我们看到性能有明显的提升，为什么P参数到了一定量之后性能就上不去了呢？