Redis学习笔记 - pipline（流水线、管道）

一、什么是 pipline

大多数同学一直以来对 Redis 管道有一个误解，他们以为这是 Redis 服务器提供的一种特别的技术，有了这种技术就可以加速 Redis 的存取效率。但是实际上 Redis 管道 (Pipeline) 本身并不是 Redis 服务器直接提供的技术，这个技术本质上是由客户端提供的，跟服务器没有什么直接的关系。

1. 一次网络命令的通信模型

1次网络命令时间 = 1次网络传输时间（往返） + 1次命令执行时间

 

2. 批量网络命令的通信模型

n次网络命令时间 = n次网络传输时间（往返） + n次命令执行时间

 

3. pipline可以打包n条命令，一次性传输到服务端，再按顺序返回命令的执行结果

1次pipline(n条命令)网络命令时间 = 1次网络传输时间（往返） + n次命令执行时间

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

Redis命令执行的时间一般是微秒级，速度非常快。
因此，网络传输通常会成为redis性能的瓶颈。
此时，节省网络传输时间是非常重要的。

深入理解管道本质

接下来我们深入分析一个请求交互的流程，真实的情况是它很复杂，因为要经过网络协议栈，这个就得深入内核了。

上图就是一个完整的请求交互流程图，我用文字来仔细描述一遍：

1. 客户端进程调用write将消息写到操作系统内核为套接字分配的发送缓冲send buffer。
2. 客户端操作系统内核将发送缓冲的内容发送到网卡，
   网卡硬件将数据通过「网际路由」送到服务器的网卡。
3. 服务器操作系统内核将网卡的数据放到内核为套接字分配的接收缓冲recv buffer。
4. 服务器进程调用read从接收缓冲中取出消息进行处理。
5. 服务器进程调用write将响应消息写到内核为套接字分配的发送缓冲send buffer。
6. 服务器操作系统内核将发送缓冲的内容发送到网卡，
   网卡硬件将数据通过「网际路由」送到客户端的网卡。
7. 客户端操作系统内核将网卡的数据放到内核为套接字分配的接收缓冲recv buffer。
8. 客户端进程调用read从接收缓冲中取出消息返回给上层业务逻辑进行处理。
9. 结束。

其中步骤 5~8 和 1~4 是一样的，只不过方向是反过来的，一个是请求，一个是响应。我们开始以为 write 操作是要等到对方收到消息才会返回，但实际上不是这样的。write 操作只负责将数据写到本地操作系统内核的发送缓冲然后就返回了。剩下的事交给操作系统内核异步将数据送到目标机器。但是如果发送缓冲满了，那么就需要等待缓冲空出空闲空间来，这个就是写操作 IO 操作的真正耗时。

我们开始以为 read 操作是从目标机器拉取数据，但实际上不是这样的。read 操作只负责将数据从本地操作系统内核的接收缓冲中取出来就了事了。但是如果缓冲是空的，那么就需要等待数据到来，这个就是读操作 IO 操作的真正耗时。

所以对于value = redis.get(key)这样一个简单的请求来说，write操作几乎没有耗时，直接写到发送缓冲就返回，而read就会比较耗时了，因为它要等待消息经过网络路由到目标机器处理后的响应消息,再回送到当前的内核读缓冲才可以返回。这才是一个网络来回的真正开销。

而对于管道来说，连续的write操作根本就没有耗时，之后第一个read操作会等待一个网络的来回开销，然后所有的响应消息就都已经回送到内核的读缓冲了，后续的 read 操作直接就可以从缓冲拿到结果，瞬间就返回了。

 

二、pipline与原生批量操作的对比

之前我们讲过 M 操作，也是类似 pipeline，将多个命令一次执行，一次发送出去，节省网络时间。对比如下：

• M操作在Redis队列中是一个原子操作，pipeline不是原子操作
• pipeline与M操作都会将数据顺序的传送顺序地返回（redis 单线程）
• M 操作一个命令对应多个键值对，而Pipeline是多条命令

1. mget、mset等原生批量操作

mget、mset等批量操作是原子操作

2. pipline

pipline是非原子操作

 

三、使用建议

1. 注意每次pipline携带的数据量，数据量不宜过大
2. pipline每次只能作用在一个Redis节点上