Redis如何解决频繁的命令往返造成的性能瓶颈

前言

先来看看Redis客户端和服务端的交互模型

「可以得出:」

1.Redis是基于一个Request,一个Response的同步请求服务

2.客户端将数据包发送至服务器,然后服务器再将响应数据发送回客户端,这都需要花费一定时间的。这段时间被称为往返时间RTT(Round Trip Time)。

当一个客户端需要连续执行很多请求时,就很容易看出往返时间是影响系统性能的

例如:如果往返时间RTT是250毫秒,即使Redis服务器每秒钟能处理1000个请求,我们也只能每秒钟最多处理四个请求。

「Redis提供了一种Pipeline(管道)方法可以改善上述用例的性能,下面看看。」

Redis Pipeline交互模型

可以看到,客户端首先将执行的命令写入到缓冲区(内存)中,最后再一次性发送 Redis。

pipeline通过将一批命令进行打包,然后发送给服务器,服务器执行完按顺序打包返回,这样就减少了频繁交互往返的时间,提升了性能

基本使用

使用起来还是很简单的

Pipeline的本质

我们深入分析一个请求交互的流程,真实的情况是它很复杂的

「上图就是一个完整的请求交互流程图:」

客户端调用write将消息写到操作系统内核为套接字分配的发送缓冲中send buffer

系统内核将缓冲区的内容发送到网卡,网卡硬件将数据通过路由送到服务器的网卡

服务器网卡将数据放到内核为套接字分配的接收缓冲中recive buffer

服务器调用read从接收缓冲中取出消息进行处理

服务器调用write将响应内容发送到send bffer中

服务器内核将缓冲区的内容通过路由发送到客户端的网卡中

客户端内核将网卡中的数据放到接收缓冲中recive buffer

客户端调用read从缓冲中读取数据

「总结」

我们开始以为 write 操作是要等到对方收到消息才会返回,但实际上不是这样的。

写操作 IO 操作的真正耗时

write 操作只负责将数据写到本地操作系统内核的发送缓冲然后就返回了。剩下的事交给操作系统内核异步将数据送到目标机器。但是如果发送缓冲满了,那么就需要等待缓冲空出空闲空间来,这个就是写操作 IO 操作的真正耗时。

读操作 IO 操作的真正耗时

我们开始以为 read 操作是从目标机器拉取数据,但实际上不是这样的。read 操作只负 责将数据从本地操作系统内核的接收缓冲中取出来就了事了。但是如果缓冲是空的,那么就 需要等待数据到来,这个就是读操作 IO 操作的真正耗时。

value = redis.get(key)操作耗时

对于 value = redis.get(key)这样一个简单的请求来说,write 操作几乎没有耗时,直接 写到发送缓冲就返回,而 read 就会比较耗时了,因为它要等待消息经过网络路由到目标机器 处理后的响应消息,再回送到当前的内核读缓冲才可以返回。

管道的真正耗时

对于管道来说,连续的 write 操作根本就没有耗时,之后第一个 read 操作会等待一个 网络的来回开销,然后所有的响应消息就都已经回送到内核的读缓冲了,后续的 read 操作 直接就可以从缓冲拿到结果,瞬间就返回了。

优缺点

「Pipeline的优点:」

pipeline 通过打包命令,一次性执行,可以节省连接->发送命令->返回结果这个过程所产生的往返时间,减少的I/O的调用(用户态到内核态之间的切换)次数。

「Pipeline的缺点:」

pipeline 每批打包的命令不能过多,因为 pipeline 方式打包命令再发送,那么 redis 必须在处理完所有命令前先缓存起所有命令的处理结果。这样就有一个内存的消耗。

pipeline不保证原子性,执行命令过程中,如果一个命令出现异常,也会继续执行其他命令,所以如果要求原子性的,不推荐使用 pipeline

pipeline每次只能作用在一个Redis节点上(下面会解释原因)

适用场景

有些系统可能对可靠性要求很高,每次操作都需要立马知道这次操作是否成功,是否数据已经写进redis了,那这种场景就不适合。

有的系统,可能是批量的将数据写入redis,允许一定比例的写入失败,那么这种场景就可以使用了,比如10000条一下进入redis,可能失败了2条无所谓,后期有补偿机制就行了

比如短信群发这种场景,如果一下群发10000条,按照第一种模式去实现,那这个请求过来,要很久才能给客户端响应,这个延迟就太长了,如果客户端请求设置了超时时间5秒,那肯定就抛出异常了,而且本身群发短信要求实时性也没那么高,这时候用pipeline最好了。

使用建议

Pipeline虽然好用,但是每次Pipeline组装的命令个数不能没有节制,否则一次组装Pipeline数据量过大,一方面会增加客户端的等待时间,另一方面会造成一定的网络阻塞,可以将一次包含大量命令的Pipeline拆分成多次较小的Pipeline来完成

Pipeline压力测试

Redis 自带了一个压力测试工具 redis-benchmark,使用这个工具就可以进行管道测试。

小贴士:redis-benchmark官方文档:https://redis.io/topics/benchmarks

首先我们对一个普通的 set 指令进行压测,QPS 大约 5w/s。

我们加入管道选项-P 参数,它表示单个管道内并行的请求数量,看下面 P=2,QPS 达到 了 9w/s。

再看看 P=3,QPS 达到了 10w/s。

SET:102354.15requests persecond

但如果再继续提升 P 参数,发现 QPS 已经上不去了。这是为什么呢?

因为这里 CPU 处理能力已经达到了瓶颈,Redis 的单线程 CPU 已经飙到了 100%,所 以无法再继续提升了。

其他问题

「为什么pipeline只能作用在一个Redis节点上,即集群模式下不能使用pipeline?」

我们知道,Redis 集群的键空间被分割为 16384 个槽(slot),每个主节点都负责处理 16384 个哈希槽的其中一部分。

具体的redis命令,会根据key计算出一个槽位(slot),然后根据槽位去特定的节点redis上执行操作。如下所示:

集群有三个master节点组成,其中master1分配了 0~5460的槽位,master2分配了 5461~10922的槽位,master3分配了 10923~16383的槽位。

一次pipeline会批量执行多个命令,那么每个命令都需要根据key运算一个槽位(CRC16.getSlot(key)),然后根据槽位去特定的节点上执行命令,也就是说一次pipeline操作会使用多个节点的redis连接,而目前是无法支持的

「pipeline和mget、mset等批量操作区别?」

mget,mset也是类似 pipeline,将多个命令一次执行,一次发送出去,节省网络时间。

对比如下:

mset,mget操作在Redis队列中是一个原子操作,pipeline不是原子操作

mset,mget操作一个命令对应多个键值对,而pipeline是多条命令

mset,mget是服务端实现,而pipeline是服务端和客户端共同完成

「pipeline和事务区别?」

pipeline关注的是RTT时间,而事务关注的是一致性

pipeline是一次请求,服务端顺序执行,一次返回,事务多次请求(MULTI命令+其他n个命令+EXEC命令,所以至少是2次请求),服务端顺序执行,一次返回。

集群模式下,使用pipeline时,slot槽必须是对的,不然服务端会返回redirecred to slot xxx的错误;同时不建议使用事务,因为假设一个事务中的命令即在Master A上执行,也在Master B执行,A成功了,B因为某种原因失败了,这样数据就不一致了,这个有点类似于分布式事务,无法保证绝对一致性。

「Pipeline对命令数量是否有限制?」

没有限制,但是打包的命令不能过多,对内存的消耗就越大。

「Pipeline打包执行多少命令合适?」

查询 Redis 官方文档,根据官方文档的解释,推荐是以 10k 每批 (注意:这个是一个参考值,请根据自身实际业务情况调整)。

「Pipeline批量执行的时候,是否导致其他应用无法再进行读写?」

Redis 采用多路I/O复用模型,非阻塞IO,所以Pipeline批量写入的时候,一定范围内不影响其他的读操作。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 219,539评论 6 508
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 93,594评论 3 396
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 165,871评论 0 356
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,963评论 1 295
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,984评论 6 393
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,763评论 1 307
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,468评论 3 420
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,357评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,850评论 1 317
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 38,002评论 3 338
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 40,144评论 1 351
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,823评论 5 346
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,483评论 3 331
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 32,026评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 33,150评论 1 272
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 48,415评论 3 373
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 45,092评论 2 355

推荐阅读更多精彩内容