Redis 6.0 多线程IO处理过程详解

Redis 6.0 多线程IO处理过程详解

大半年前,看到Redis即将推出“多线程IO”的特性,基于当时的各种资料,和unstable分支的代码,写了《多线程的 Redis》,浅尝辄止地介绍了下特性,不够华也不实。本文将深入到实处,内容包含:

  • 介绍Redis单线程IO处理过程
  • 单线程的问题
  • 解析Redis多线程IO如何工作

要分析多线程IO,必须先搞清楚经典的单线程异步IO。文章会先介绍单线程IO的知识,然后再引出多线程IO,如果已经熟悉,可以直接跳到多线程IO部分。

接下来我们一起啃下这两块大骨头。代码基于: github.com/antirez/redi

异步处理IO

Redis 核心的工作负荷是一个单线程在处理, 但为什么还那么快?

  • 其一是纯内存操作。
  • 其二就是IO数据的处理是异步的,每个命令从接收到处理,再到返回,会经历多个“不连续”的工序。

为避免歧义,此处的异步处理IO不是“同步/异步IO”,特指IO处理过程是异步的,描述的对象是处理过程。

假设客户端发送了以下命令:

GET key-how-to-be-a-better-man?

redis回复:

努力加把劲把文章写完

要处理命令,则redis必须完整地接收客户端的请求,并将命令解析出来,再将结果读出来,通过网络回写到客户端。整个工序分为以下几个部分:

  • 接收。通过TCP接收到命令,可能会历经多次TCP包、ack、IO操作
  • 解析。将命令取出来
  • 执行。到对应的地方将value读出来
  • 返回。将value通过TCP返回给客户端,如果value较大,则IO负荷会更重

其中解析和执行是纯cpu/内存操作,而接收和返回主要是IO操作,这是我们要关注的重点。以接收为例,redis要完整接收客户端命令,有两种策略:

  • 接收客户端命令时一直等,直到接收到完整的命令,然后执行,再将结果返回,直到客户端收到完整结果, 然后才处理下一个命令。 这叫同步。 同步的过程中有很多等待的时间,例如有个客户端网络不好,那等它完整的命令就会更耗时。
  • 客户端的TCP包来一个才处理一个,将数据追加到缓冲区,处理完了就去立即找其他事做,不等待,下一个TCP包来了再继续处理。命令的接收过程是穿插的,不连续。一会儿接收这个命令,一会儿又在接收另一个。 这叫做异步,过程中没有额外的空闲等待时间。

用聊天的例子做对应,假设你在回答多个人的问题,也有同步和异步的策略:

  • 聊天框中显示“正在输入”时,你一直等ta输入完毕,然后回答ta的问题,再发送出去,发送时会有等待,常规表现就是有个圆圈在转。你等发送完毕后,才去回答另一个人的问题。 同步
  • 显示“正在输入”时,不等ta,而是去回答其他输入完毕的问题,回答完后,不等发送完毕,又去回答其它问题。 异步

很显然异步的效率更高,要实现高并发必须要异步,因为同步有太多时间浪费在等待上了,遇到网络不好的客户端直接就被拖垮。异步的策略简单可总结如下:

  • 网络包有数据了,就去读一下放到缓冲区,读完立马切到其他事情上,不等下一个包
  • 解析下缓冲区数据是否完整。如完整则执行命令,不完整切到其他事情上
  • 数据完整了,立即执行命令,将执行结果放到缓冲区
  • 将数据给客户端,如果一次给不完,就等下次能给时再给,不等,直到全部给完

事件驱动

异步没有零散的等待,但有个问题是,如果redis不一直阻塞等命令来,咋个知道“网络包有数据了”、“下次能给时”这两个时机? 如果一直去轮训问肯定效率很低,要有个高效的机制,来通知redis这两个时刻,由这些时刻来触发动作。 这就是事件驱动。

一个新TCP包来了可以再次发给客户端数据这两个时机都是事件。与之对应的就是redis和客户端之间socket的可读、可写事件[1] ,就像微信聊天中新消息提醒一样。 linux中的epoll就是干这个事的,redis基于epoll等机制抽象出了一套事件驱动框架[2],整个server完全由事件驱动,有事件发生就处理,没有就空闲等待。

单线程IO处理过程

redis启动后会进入一个死循环aeMain,在这个循环里一直等待事件发生,事件分为IO事件和timer事件,timer事件是一些定时执行的任务,如expire key等,本文只聊IO事件。

epoll处理的是socket的可读、可写事件,当事件发生后提供一种高效的通知方式, 当想要异步监听某个socket的读写事件时,需要去事件驱动框架中注册要监听事件的socket,以及对应事件的回调function。然后死循环中可以通过epoll_wait不断地去拿发生了可读写事件的socket,依次处理即可。

可读可以简单理解为,对应的socket中有新的tcp数据包到来。
可写可以简单理解为,对应的socket写缓冲区已经空了(数据通过网络已经发给了客户端)

一图胜前言,完整、详细流程图如下:

redis单线程IO详细流程
  • aeMain() 内部是一个死循环,会在epoll_wait处短暂休眠
  • epoll_wait返回的是当前可读、可写的socket列表
  • beforeSleep是进入休眠前执行的逻辑,核心是回写数据到socket
  • 核心逻辑都是由IO事件触发,要么可读,要么可写,否则执行timer定时任务
  • 第一次的IO可读事件,是监听socket(如监听6379的socket),当有握手请求时,会执行accept调用,得到一个连接socket,注册可读回调createClient,往后客户端和redis的数据都通过这个socket进行
  • 一个完整的命令,可能会通过多次readQueryFromClient才能从socket读完,这意味这多次可读IO事件
  • 命令执行的结果会写,也是这样,大概率会通过多次可写回调才能写完
  • 当命令被执行完后,对应的连接会被追加到 clients_pending_write,beforeSleep会尝试回写到socket,写不完会注册可写事件,下次继续写
  • 整个过程IO全部都是同步非阻塞,没有浪费等待时间
  • 注册事件的函数叫aeCreateFileEvent

单线程IO的瓶颈

上面详细梳理了单线程IO的处理过程,IO都是非阻塞,没有浪费一丁点时间,虽然是单线程,但动辄能上10W QPS。不过也就这水平了,难以提供更多的自行车。

同时这个模型有几个缺陷:

  • 只能用一个cpu核(忽略后台线程)
  • 如果value比较大,redis的QPS会下降得很厉害,有时一个大key就可以拖垮
  • QPS难以更上一层楼

redis主线程的时间消耗主要在两个方面:

  • 逻辑计算的消耗
  • 同步IO读写,拷贝数据导致的消耗

当value比较大时,瓶颈会先出现在同步IO上(假设带宽和内存足够),这部分消耗在于两部分:

  • 从socket中读取请求数据,会从内核态将数据拷贝到用户态 (read调用)
  • 将数据回写到socket,会将数据从用户态拷贝到内核态 (write调用)

这部分数据读写会占用大量的cpu时间,也直接导致了瓶颈。 如果能有多个线程来分担这部分消耗,那redis的吞吐量还能更上一层楼,这也是redis引入多线程IO的目的。[3]

多线程IO

上面已经梳理了单线程IO的处理流程,以及多线程IO要解决的问题,接下来将目光放到: 如何用多线程分担IO的负荷。其做法用简单的话来说就是:

  • 用一组单独的线程专门进行 read/write socket读写调用 (同步IO)
  • 读回调函数中不再读数据,而是将对应的连接追加到可读clients_pending_read的链表
  • 主线程在beforeSleep中将IO读任务分给IO线程组
  • 主线程自己也处理一个IO读任务,并自旋式等IO线程组处理完,再继续往下
  • 主线程在beforeSleep中将IO写任务分给IO线程组
  • 主线程自己也处理一个IO写任务,并自旋式等IO线程组处理完,再继续往下
  • IO线程组要么同时在读,要么同时在写
  • 命令的执行由主线程串行执行(保持单线程)
  • IO线程数量可配置

完整流程图如下:

redis多线程IO处理流程

beforesleep中,先让IO线程读数据,然后再让IO线程写数据。 读写时,多线程能并发执行,利用多核。

  1. 将读任务均匀分发到各个IO线程的任务链表io_threads_list[i],将io_threads_pending[i] 设置为对应的任务数,此时IO线程将从死循环中被激活,开始执行任务,执行完毕后,会将 io_threads_pending[i]清零。 函数名为: handleClientsWithPendingReadsUsingThreads
  2. 将写任务均匀分发到各个IO线程的任务链表io_threads_list[i],将io_threads_pending[i] 设置为对应的任务数,此时IO线程将从死循环中被激活,开始执行任务,执行完毕后,会将 io_threads_pending[i]清零。 函数名为: handleClientsWithPendingWritesUsingThreads
  3. beforeSleep中主线程也会执行其中一个任务(图中忽略了),执行完后自旋等待IO线程处理完。
  4. 读任务要么在beforeSleep中被执行,要么在IO线程被执行,不会再在读回调中执行
  5. 写任务会分散到 beforeSleep、IO线程、写回调中执行
  6. 主线程和IO线程交互是无锁的,通过标志位设置进行,不会同时写任务链表

性能据测试提升了一倍以上(4个IO线程)。 [4]

欢迎您的提问、指正、建议等。

参考

  1. cnblogs.com/my_life/art
  2. mp.weixin.qq.com/s/5Szb
  3. toutiao.com/a6816914695
  4. chainnews.com/articles/
编辑于 07-26

文章被以下专栏收录