Redis——Pipeline(过时并不代表不精髓)

举报
李子捌 发表于 2021/10/15 13:31:10 2021/10/15
【摘要】 Redis客户端和服务端之间通过网络连接进行数据传输,这个连接可以很快(loopback接口)或很慢(建立了一个多次跳转的网络连接)。无论网络延如何延时,数据包总是能从客户端到达服务器,并从服务器返回数据回复客户端,这个时间被称之为RTT(Round Trip Time - 往返时间)。我们可以很容易就意识到,Redis在连续请求服务端时,即使Redis每秒能处理100k请求,但也会因为网络传输…

1、简介

Redis是一种基于客户端-服务端模型以及请求/响应的TCP服务。一次Redis客户端发起的请求,经过服务端的响应后,大致会经历如下的步骤:

  1. 客户端发起一个(查询/插入)请求,并监听socket返回,通常情况都是阻塞模式等待Redis服务器的响应
  2. 服务端处理命令,并且返回处理结果给客户端
  1. 客户端接收到服务的返回结果,程序从阻塞代码处返回


Redis客户端和服务端之间通过网络连接进行数据传输,这个连接可以很快(loopback接口)或很慢(建立了一个多次跳转的网络连接)。无论网络延如何延时,数据包总是能从客户端到达服务器,并从服务器返回数据回复客户端,这个时间被称之为RTT(Round Trip Time - 往返时间)。我们可以很容易就意识到,Redis在连续请求服务端时,即使Redis每秒能处理100k请求,但也会因为网络传输花费大量时间,导致整体性能的下降。


因此如果遇到大量的批处理,我们可以考虑使用Redis的pipeline(管道)。值得注意的是,管道技术并不是Redis特有的技术,管道技术往往需要客户端-服务器的共同配合,大部分工作任务其实是在客户端完成,很显然Redis支持管道技术,按照官网的意思,Redis的最低版本就考虑了管道技术的支持性设计。


如下图,多个连续的incr指令,使用pipeline(管道)后,多个连续的incr指令只会花费一次网络来回开销,这个开销会随着n数值的增大,大幅减少网络io开销,从而提升整体服务的性能。


2、深究pipeline

在上述简介中,提到了管道技术优化的是网络传输的耗时时间,这里通过Redis客户端-服务端的一次完整的网络请求来回,深入探索pipeline的本质。

  1. 客户端调用write将数据写入操作系统内核(kernel)为socket连接分配的发送缓冲区(send buffer)
  2. 客户端操作系统内核将发送缓冲区(send buffer)的数据发送到网卡(NIC)
  1. 网卡(NIC)将数据通过路由(route)将数据送到Redis服务器机器网卡(NIC)
  2. 服务器操作系统内核(kernel)将网卡(NIC)接收的数据,写入内核为socket分配的接收缓冲区(recv buffer)
  1. 服务器进程从接收缓冲区调用read读取数据,并进行数据逻辑处理
  2. 数据处理完成之后,服务器进程调用write将响应数据写入操作系统内核为socket分配的发送缓冲区
  1. 操作系统内核将发送缓冲区的数据发送到服务器网卡
  2. 服务器网卡将响应数据通过路由发送到客户端网卡
  1. 客户端网卡接收响应数据
  2. 客户端操作系统内核读取网卡接收到的服务器响应数据,并写入操作系统为socket连接分配的介绍缓冲区
  1. 客户端进程调用read从接收缓冲区中读取服务器响应数据
  2. 一次完整网络请求来回过程结束


对于pipeline技术而言,就是将n * 12个步骤,合并成1 * 12,这样服务请求响应的总体时间将会大大的减少。


有个值得注意的点:

在上述网络请求来回中,可能出现我们经常说到的io阻塞:

  1. 当write操作发生,并且发送缓冲区(send buffer)满时,就会导致write操作阻塞
  2. 当read操作发生,并且接收缓冲区(recv buffer)满时,就会导致read操作阻塞

上述的这两个阻塞如果出现,将会导致整个请求时间变长,因此我们操作大批量指令的时候,比如10k个指令,我们可以合理的对指令分多次批量发送,这样可以减少出现阻塞的情况,也可以避免服务器响应一个过大的答复包,导致客户端内存负载过重。


3、benchmark压测pipeline

使用Redis提供的benchmark对Redis进行性能测试,

如过你是Windows下的Redis,在安装目录下有个redis-benchmark.exe,进入cmd命令模式测试即可

如果你是在Linux下的redis,在安装目录的src目录下有个redis-benchmark

redis-benchmark的全部指令参数如下所示,我们这里测试pipeline,需要使用-P

指令名称

描述

默认值

-h

指定Redis服务器hostname

127.0.0.1

-p

指定Redis服务器端口

6379

-s

指定Redis服务器Server Socket

-a

指定Redis服务器密码

-c

指定客户端并发数

50

-n

指定总请求数

100000

-dbnum

指定Redis数据库

0

-k

1=keep alive 0=reconnect

1

-r

使用随机key,value 对相关指令进行压测

-P

使用管道(pipeline)

1(no pipeline)

-q

强制退出Redis,仅展示query/sec

--csv

使用CSV格式输出

-l

循环运行测试

-t

运行逗号分隔的测试列表

-I

Idle模式,仅打开N个idle连接并等待

通过普通方式测试set指令和pipeline方式测试set指令,可以看到Redis服务不同的QPS:

  • 普通set方式,Redis QPS 大概在5.3万左右
  • 当使用pipeline set时,随着管道内并行请求数量的增加,Redis QPS可以达到100万以上


4、Jedis使用pipeline

测试代码

package com.liziba.redis;

import redis.clients.jedis.Jedis;
import redis.clients.jedis.Pipeline;

import java.io.IOException;

/**
 * <p>
 * 测试pipeline
 * </p>
 *
 * @Author: Liziba
 * @Date: 2021/9/14 22:43
 */
public class PipelineTest {

    public static void main(String[] args) throws IOException {
        Jedis client = new Jedis("127.0.0.1", 6379);

        long startPipe = System.currentTimeMillis();
        Pipeline pipe = client.pipelined();
        pipe.multi();
        for (int i = 0; i < 100000; i++) {
            pipe.set("pipe" + i, i + "" );
        }
        pipe.exec();
        pipe.close();
        long endPipe = System.currentTimeMillis();
        System.out.println("pipeline set cost time : " + (endPipe - startPipe) + "ms");


        for (int i = 0; i < 100000; i++) {
            client.set("normal" + i, i + "");
        }
        System.out.println("normal set cost time : " + (System.currentTimeMillis() - endPipe)+ "ms");
    }

}

测试结果

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。