• 首页 首页 icon
  • 工具库 工具库 icon
    • IP查询 IP查询 icon
  • 内容库 内容库 icon
    • 快讯库 快讯库 icon
    • 精品库 精品库 icon
    • 问答库 问答库 icon
  • 更多 更多 icon
    • 服务条款 服务条款 icon

Redis17Redis进阶管道

武飞扬头像
码农老张Zy
帮助1

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

  1.  
    ➜  (printf "PING\r\nPING\r\nPING\r\n"; sleep 1) | nc localhost 6379
  2.  
    PONG
  3.  
    PONG
  4.  
    PONG

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

  1.  
    ➜ 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
  2.  
     
  3.  
    All data transferred. Waiting for the last reply...
  4.  
    Last reply received from server.
  5.  
    errors: 0, replies: 2
  6.  
     
  7.  
    ➜  redis-cli
  8.  
    127.0.0.1:6379> get a
  9.  
    "112"

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

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

  1.  
    // main.go
  2.  
    t1 := time.Now()
  3.  
     
  4.  
    for i := 1; i < 100000; i  {
  5.  
     rdb.Set("info:" strconv.Itoa(i), "val"-1)
  6.  
    }
  7.  
     
  8.  
    t2 := time.Now()
  9.  
     
  10.  
    fmt.Println(t2.Sub(t1))
  11.  
     
  12.  
    // 命令行执行结果
  13.  
    ➜ go run main.go 
  14.  
    5.374380805s

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

  1.  
    // main.go
  2.  
    t1 := time.Now()
  3.  
     
  4.  
    pipe := rdb.Pipeline()
  5.  
    for i := 1; i < 100000; i  {
  6.  
     pipe.Set("info:" strconv.Itoa(i), "val"-1)
  7.  
    }
  8.  
    pipe.Exec()
  9.  
     
  10.  
    t2 := time.Now()
  11.  
     
  12.  
    fmt.Println(t2.Sub(t1))
  13.  
     
  14.  
    // 命令行执行结果
  15.  
    ➜  go run main.go
  16.  
    299.236659ms
学新通

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

  1.  
    // pipe.php
  2.  
    $redis = new \Redis();
  3.  
    $redis->connect('127.0.0.1');
  4.  
    $redis->flushDB();
  5.  
     
  6.  
    $t1 = microtime(true);
  7.  
     
  8.  
    $pipe = $redis->pipeline();
  9.  
    for($i=0;$i<100000;$i ){
  10.  
      $pipe->set("info:".$i, "val");
  11.  
    }
  12.  
    $pipe->exec();
  13.  
     
  14.  
    $t2 = microtime(true);
  15.  
    echo $t2-$t1;
  16.  
     
  17.  
    // 命令行执行结果
  18.  
    ➜ php pipe.php
  19.  
    0.2947039604187
学新通

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

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

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

额外

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

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

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

  1.  
    unixsocket /tmp/redis.sock
  2.  
    unixsocketperm 700

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

  1.  
    ➜ go run main.go
  2.  
    428.709968ms

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

管道与脚本

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

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

总结

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

参考文档:

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

代码地址:

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

这篇好文章是转载于:学新通技术网

  • 版权申明: 本站部分内容来自互联网,仅供学习及演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系,请提供相关证据及您的身份证明,我们将在收到邮件后48小时内删除。
  • 本站站名: 学新通技术网
  • 本文地址: /boutique/detail/tanhgcgkai
系列文章
更多 icon
同类精品
更多 icon
继续加载