Redis-pipeline

注意事项

cluster并不支持pipeline操作，不知道有没有什么好的方法

本质

是一个客户端的行为,跟服务器无关.
批量 减少IO
pipeline通过减少客户端与redis的通信次数来实现降低往返延时时间，而且Pipeline 实现的原理是队列，
就是说可以把多条指令放入到一个tcp报文一起发送，server则可以将三条命令的处理结果放到一个tcp报文返回。
主要是TCP连接中减少了“交互往返”的时间。

一次 pipeline

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 操作直接就可以从缓冲拿到结果，瞬间就返回了。

注意事项

1. pipeline期间将“独占”链接，此期间将不能进行非“管道”类型的其他操作，直到pipeline关闭；
   如果你的pipeline的指令集很庞大，为了不干扰链接中的其他操作，你可以为pipeline操作新建Client链接，
   让pipeline和其他正常操作分离在2个client中。

2. pipeline方式打包命令发送，redis必须在处理完所有命令前先缓存起所有命令的处理结果。
   打包的命令越多，缓存消耗内存也越多。所以并不是打包的命令越多越好。具体多少合适需要根据具体情况测试

3. pipeline事实上所能容忍的操作个数，和socket-output缓冲区大小/返回结果的数据尺寸都有很大的关系(默认每个套接字 缓冲区的大小为 8K)；
   同时也意味着每个redis-server同时所能支撑的pipeline链接的个数，也是有限的，这将受限于server的物理内存或网络接口的缓冲能力。

适用场景

1. 不合适一次操作强依赖结果的值
2. 支持批量操作,有一两个失败也不影响那种

参考

socket缓冲区
CSDN pipeline