Redis高效性探索--管道

骑猪看日落 2022-12-20 12:46 115阅读 0赞

#### 管道 ####

*  开始接触Redis时候，对应Redis管道有一个错误认识，任务是redis服务器提供的一种特别的技术，有了这种技术可以加速Redis的存取效率，但是实际上Redis的管道计算（Pipeline）本身是客户端提供的技术，与服务端无关。

##### Redis消息交互 #####

*  当我们使用客户端对Redis服务器发送消息指令，客户端将请求发送给服务器，服务器处理完后响应信息返回给客户端，需要花费一个网络数据报的来回时间。
 *  如果联系执行多条指令，会花费多个网络数据报的来回时间，如下图

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpYW9qaWFtaW4wMTAy_size_16_color_FFFFFF_t_70_pic_center]

*  多条指令的时候，客户端经历了写–读--写–读四个操作完成整改两条指令。
 *  假如我们跳转顺序，编程：写–写--读–读，那么同样是两个指令是不是可以将写入信息打包发送，读取的信息打包返回，如下图：  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpYW9qaWFtaW4wMTAy_size_16_color_FFFFFF_t_70_pic_center 1]
 *  这便是Redis客户端管道操作的本质作用，服务器并没有区别对待，还是走一条消息，一次执行，回复一条消息的正常流程，客户端通过对管道列表改变读写顺序就可以大幅度节省IO时间。管道中指令越多越好。

##### 深入理解管道工作流程 #####

*  上一节中有一个完整的Redis指令请求的流行，我们拿来，如下

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpYW9qaWFtaW4wMTAy_size_16_color_FFFFFF_t_70_pic_center 2]

*  如上刘冲中我们逐步分析作用

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

*  以上是所有步骤，其中5 ~ 8 和 1 ~ 4 是一样的，只不过方向反过来，一个请求一个响应
 *  我们从上面步骤看出
    
     *  服务器的write操作不需要等对方收到消息才返回，他实际上只负责将数据写入到本地操作系统内核的发送缓冲区中，生效的由操作系统自己将数据发送到客户端机器，如果缓冲区满那么需要等待缓冲区空闲，这个才是写操作IO的耗时
     *  客户端的read操作并不是从服务器直接拉去数据，他实际上只负责将数据从本地操作系统的内核的接收缓冲区取出数据，如果缓存区是空的，那么需要等待数据到来，这个才是read操作IO的实际时间
 *  案例，value = RedisDao.get(key)
    
     *  客户端将指令写入缓冲区，返回，几乎无消耗
     *  客户端read需要等待消息经过网络路由到目标机器处理后的响应消息，在回送到当前的内核读缓冲才可以返回，这个是网络的真正开销
 *  如上案例也可以看出，对于管道来说，连续的write操作根本没有耗时，之后第一个read操作会等待一个网络来回的的开销，然后后续所有响应消息也会打包一起回到内核的读缓冲区，效率大增

[上一篇：Redis高效性探索–线程IO模型，通信协议][Redis_IO]  
[下一篇：Redis持久化-深入理解AOF，RDB][Redis_-_AOF_RDB]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpYW9qaWFtaW4wMTAy_size_16_color_FFFFFF_t_70_pic_center]: /images/20221120/4bc0650d5e714e44b1b672c21908c835.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpYW9qaWFtaW4wMTAy_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20221120/2cddbd34c5cc4fa4bbddc27372f32696.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpYW9qaWFtaW4wMTAy_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20221120/1e17bd23582543f0b19c99066a0a5152.png
[Redis_IO]: https://blog.csdn.net/liaojiamin0102/article/details/109624931
[Redis_-_AOF_RDB]: https://blog.csdn.net/liaojiamin0102/article/details/109640555