标题:【Redis17】Redis进阶:管道

文章目录
    分类:存储运维 标签:Redis

    Redis进阶:管道

    管道是啥?我们做开发的同学们经常会在 Linux 环境中用到管道命令,比如 ps -ef | grep php 。在之前学习 Laravel框架时的 【Laravel6.4】管道过滤器https://mp.weixin.qq.com/s/CK-mcinYpWCIv9CsvUNR7w 这篇文章中,我们也详细的讲过管道这个概念。如果有不清楚的小伙伴可以回去复习一下哦。


    在 Redis 中,也有管道的概念。不过说白了,就是为了节省网络连接的通信成本而让多个操作一次发送。没错,概念就是这么简单。不过,咱们还是要好好掰扯掰扯到底是为啥要这样。

    请求与响应

    Redis 服务大部分情况下也是一个传统的 TCP 服务,客户端需要通过 TCP 连接到服务端,然后把命令发送到服务端,服务端处理完成后再返回给客户端。用我们这些 Web 工程师最熟悉的概念来说,就是一个请求和响应的过程。


    既然有了这个过程,那么必然的,在请求和响应的传输过程中,网络带来的性能损耗肯定是会存在的。内网或本机传输还好,外网传输则可能会要了老命了。从一个请求发出,到一个响应接收到,这中间消耗的时间叫做 RTT(Round Trip Time 往返时间)。


    设想,如果我们执行一个命令,RTT 用了 250ms ,那么一秒我们就只能执行 4 个命令。本身对于 Redis 来说,执行速度是非常快的,毕竟咱们操作的是内存。结果因为 RTT 的原因,被网络传输的速度给拖慢了,这就得不偿失了嘛。


    那么,是不是可以把多条命令合在一起,然后一起发送出去呢?这样同样的 RTT 时间,我们就可以执行更多的命令,从而达到提高效率的目的。


    没错,就是管道啦。

    管道

    这个东西不新鲜,怎么说呢?MySQL 会吧?大批量插入的时候我们最优先选择的一个处理方案是啥?

    insert into t values (xxx,xxx),(xxx,xxx),(xxx,xxx)

    是不是这样的批量插入,为的是什么?一样的,减少来回连接 MySQL 的开销,从而加快插入速度。


    在 Redis 中也有类似的命令,要是想不起来 MSET 这个命令的话那么您得回到基础篇再好好复习一下了。不过,不只是插入,对于其它命令来说,我们通过管道的方式也能在一次请求中进行批量的执行。如果使用命令行的话,可以这样测试:

    ➜  (printf "PING\r\nPING\r\nPING\r\n"; sleep 1) | nc localhost 6379
    +PONG
    +PONG
    +PONG

    一次性发送了 3 个 PING ,返回了 3 个 PONG 。或者使用命令行客户端。

    ➜ printf "*3\r\n\$3\r\nSET\r\n\$1\r\na\r\n\$3\r\n111\r\n*2\r\n\$4\r\nincr\r\n\$1\r\na\r\n" |  redis-cli --pipe
    
    All data transferred. Waiting for the last reply...
    Last reply received from server.
    errors: 0, replies: 2
    
    ➜  redis-cli
    127.0.0.1:6379> get a
    "112"

    在应用程序的客户端中,使用就更加方便了,我们直接就来进行速度的测试,使用 SET 插入十万条数据,然后看一下不使用管道和使用管道之间的区别。


    首先是不使用管道的(Go语言测试)。

    // main.go
    t1 := time.Now()
    
    for i := 1; i < 100000; i++ {
    	rdb.Set("info:"+strconv.Itoa(i), "val", -1)
    }
    
    t2 := time.Now()
    
    fmt.Println(t2.Sub(t1))
    
    // 命令行执行结果
    ➜ go run main.go 
    5.374380805s
    

    循环插入十万条数据,耗时 5.37 秒。接下来我们再使用管道来进行插入。

    // main.go
    t1 := time.Now()
    
    pipe := rdb.Pipeline()
    for i := 1; i < 100000; i++ {
    	pipe.Set("info:"+strconv.Itoa(i), "val", -1)
    }
    pipe.Exec()
    
    t2 := time.Now()
    
    fmt.Println(t2.Sub(t1))
    
    // 命令行执行结果
    ➜  go run main.go
    299.236659ms

    是不是要起立鼓掌了,299 毫秒搞定。这里的示例语言用的是 Go ,使用的是 go-redis 这个包。我这里没有开协程,也是线性执行的哦。抛开语言因素,咱们用 PHP 再试一把。

    // pipe.php
    $redis = new \Redis();
    $redis->connect('127.0.0.1');
    $redis->flushDB();
    
    $t1 = microtime(true);
    
    $pipe = $redis->pipeline();
    for($i=0;$i<100000;$i++){
      $pipe->set("info:".$i, "val");
    }
    $pipe->exec();
    
    $t2 = microtime(true);
    echo $t2-$t1;
    
    // 命令行执行结果
    ➜ php pipe.php
    0.2947039604187

    好嘛,这回还快了 5 毫秒,294 毫秒就搞定了。


    管道就这么无敌吗?也不是全是,使用管道发送命令时,服务器将被迫回复一个队列答复,占用很多内存。所以,如果你需要发送大量的命令,最好是把他们按照合理数量分批次的处理,例如 10000 条命令,读回复,然后再发送另一个 10000 条的命令,等等。这样速度几乎是相同的,但是在每次回复这 10000 条命令队列时需要非常大量的内存用来组织返回数据内容。


    其实话说回来,Redis 足够快,平常我们的 Redis 服务也不会放到外网,基本都是内网连接,总体来说效率应该还是没问题的,除非真的是遇到上面这种需要不停执行大量命令的极端情况。因此,这套功能使用过的同学可能真的不多。

    额外

    为啥我们在本地 127.0.0.1 的这个回环连接循环执行 SET 会这么慢呢?照理说本地是没有网络开销的呀,只是内存、CPU的通信问题嘛。


    好吧,都提到内存和CPU了,那咱们也应该知道,系统进程不是总在执行同一个进程的,会有时间片调度的。当写入一个新命令的时候,会进入到回环接口的缓冲区中,然后等待系统内核安排CPU执行调度,因此,也会有像网络延迟一样的效果。


    我们可以配置 redis.conf ,打开 unixsocket 连接方式。unixsocket 是通过描述符连接的方式,不走网络回环请求,MySQL 也有这样的连接方式,但是,只能本地使用,也就是说,真实业务场景下,这样用得不多。

    unixsocket /tmp/redis.sock
    unixsocketperm 700

    然后在命令行使用 redis-cli -s /tmp/redis.sock 连接,同样也可以在程序代码中使用 unix:/tmp/redis.sock进行连接。然后再次测试不使用管道执行十万条的 SET 结果就像下面这样了。

    ➜ go run main.go
    428.709968ms

    可以看出,速度还是没有使用管道来得快。

    管道与脚本

    脚本还记得吧,就是我们之前学习过的 Lua 脚本。如果是非常大量的管道操作可以通过脚本得到更高效的处理,不过呢,前提就是你得先会 Lua ,所以说,这是应对更加极端情况下的一种选择,大部分情况下,我们使用普通的管道就已经非常够用了。


    另外就是,Lua 以及 MSET 之类的批量命令是原子的,而 Pipeline 不是,它只是将命令一起发送,到服务端后还是一条一条按顺序地执行。

    总结

    又是一个好玩的功能吧,不过确实也是一个非常冷门的功能,毕竟这货在日常的普通使用中就已经够快了,而且就像在文章中一直说过的,一次性非常大量的命令执行这种极端业务需求也是不常见的。所以,至少了解一下吧,遇到的时候至少不会抓瞎。


    参考文档:


    https://redis.io/docs/manual/pipelining/


    代码地址:


    https://github.com/zhangyue0503/dev-blog/tree/master/redis/2022/source

    视频链接

    微信文章地址:https://mp.weixin.qq.com/s/jgddd7nnrTggW-V5Nwa37Q

    B站视频地址:https://www.bilibili.com/video/BV1sV411g7Ws

    搜索
    关注