Redis缓存IO模型的演进教程示例精讲

前言

redis作为应用最广泛的nosql数据库之一,大大小小也经历过很多次升级。在4.0版本之前,单线程+IO多路复用使得redis的性能已经达到一个非常高的高度了。作者也说过,之所以设计成单线程是因为redis的瓶颈不在cpu上,而且单线程也不需要考虑多线程带来的锁开销问题。

然而随着时间的推移,单线程越来越不满足一些应用场景了,比如针对大key删除会造成主线程阻塞的问题,redis4.0出了一个异步线程。

针对单线程由于无法利用多核cpu的特性而导致无法满足更高的并发,redis6.0也推出了多线程模式。所以说redis是单线程越来越不准确了。

事件模型

redis本身是个事件驱动程序,通过监听文件事件和时间事件来完成相应的功能。其中文件事件其实就是对socket的抽象,把一个个socket事件抽象成文件事件,redis基于Reactor模式开发了自己的网络事件处理器。那么Reactor模式是什么?

通信

思考一个问题,我们的服务器是如何收到我们的数据的?首先双方先要建立TCP连接,连接建立以后,就可以收发数据了。发送方向socket的缓冲区发送数据,等待系统从缓冲区把数据取走,然后通过网卡把数据发出去,接收方的网卡在收到数据之后,会把数据copy到socket的缓冲区,然后等待应用程序来取,这是大概的发收数据流程。

Redis缓存IO模型的演进教程示例精讲_第1张图片

copy数据的开销

因为涉及到系统调用,整个过程可以发现一份数据需要先从用户态拷贝到内核态的socket,然后又要从内核态的socket拷贝到用户态的进程中去,这就是数据拷贝的开销。

数据怎么知道发给哪个socket

内核维护的socket那么多,网卡过来的数据怎么知道投递给哪个socket?

答案是端口,socket是一个四元组:

ip(client)+ port(client)+ip(server)+port(server)

注意千万不要说一台机器的理论最大并发是65535个,除了端口,还有ip,应该是端口数*ip数

这也是为什么一台电脑可以同时打开多个软件的原因。

socket的数据怎么通知程序来取

当数据已经从网卡copy到了对应的socket缓冲区中,怎么通知程序来取?假如socket数据还没到达,这时程序在干嘛?这里其实涉及到cpu对进程的调度的问题。从cpu的角度来看,进程存在运行态、就绪态、阻塞态。

  • 就绪态:进程等待被执行,资源都已经准备好了,剩下的就等待cpu的调度了。
  • 运行态:正在运行的进程,cpu正在调度的进程。
  • 阻塞态:因为某些情况导致阻塞,不占有cpu,正在等待某些事件的完成。

当存在多个运行态的进程时,由于cpu的时间片技术,运行态的进程都会被cpu执行一段时间,看着好似同时运行一样,这就是所谓的并发。当我们创建一个socket连接时,它大概会这样:

sockfd = socket(AF_INET, SOCK_STREAM, 0)
connect(sockfd, ....)
recv(sockfd, ...)
doSometing()

操作系统会为每个socket建立一个fd句柄,这个fd就指向我们创建的socket对象,这个对象包含缓冲区、进程的等待队列...。对于一个创建socket的进程来说,如果数据没到达,那么他会卡在recv处,这个进程会挂在socket对象的等待队列中,对cpu来说,这个进程就是阻塞的,它其实不占有cpu,它在等待数据的到来。

Redis缓存IO模型的演进教程示例精讲_第2张图片

当数据到来时,网卡会告诉cpu,cpu执行中断程序,把网卡的数据copy到对应的socket的缓冲区中,然后唤醒等待队列中的进程,把这个进程重新放回运行队列中,当这个进程被cpu运行的时候,它就可以执行最后的读取操作了。这种模式有两个问题:

recv只能接收一个fd,如果要recv多个fd怎么办?

通过while循环效率稍低。

进程除了读取数据,还要处理接下里的逻辑,在数据没到达时,进程处于阻塞态,即使用了while循环来监听多个fd,其它的socket是不是因为其中一个recv阻塞,而导致整个进程的阻塞。

针对上述问题,于是Reactor模式和IO多路复用技术出现了。

Reactor

Reactor是一种高性能处理IO的模式,Reactor模式下主程序只负责监听文件描述符上是否有事件发生,这一点很重要,主程序并不处理文件描述符的读写。那么文件描述符的可读可写谁来做?答案是其他的工作程序,当某个socket发生可读可写的事件后,主程序会通知工作程序,真正从socket里面读取数据和写入数据的是工作程序。这种模式的好处就是就是主程序可以扛并发,不阻塞,主程序非常的轻便。事件可以通过队列的方式等待被工作程序执行。通过Reactor模式,我们只需要把事件和事件对应的handler(callback func),注册到Reactor中就行了,比如:

type Reactor interface{
   RegisterHandler(WriteCallback func(), "writeEvent");
   RegisterHandler(ReadCallback func(), "readEvent");
}

当一个客户端向redis发起set key value的命令,这时候会向socket缓冲区写入这样的命令请求,当Reactor监听到对应的socket缓冲区有数据了,那么此时的socket是可读的,Reactor就会触发读事件,通过事先注入的ReadCallback回调函数来完成命令的解析、命令的执行。当socket的缓冲区有足够的空间可以被写,那么对应的Reactor就会产生可写事件,此时就会执行事先注入的WriteCallback回调函数。当发起的set key value执行完毕后,此时工作程序会向socket缓冲区中写入OK,最后客户端会从socket缓冲区中取走写入的OK。在redis中不管是ReadCallback,还是WriteCallback,它们都是一个线程完成的,如果它们同时到达那么也得排队,这就是redis6.0之前的默认模式,也是最广为流传的单线程redis。

整个流程下来可以发现Reactor主程序非常快,因为它不需要执行真正的读写,剩下的都是工作程序干的事:IO的读写、命令的解析、命令的执行、结果的返回..,这一点很重要。

IO多路复用器

通过上面我们知道Reactor它是一个抽象的理论,是一个模式,如何实现它?如何监听socket事件的到来?。最简单的办法就是轮询,我们既然不知道socket事件什么时候到达,那么我们就一直来问内核,假设现在有1w个socket连接,那么我们就得循环问内核1w次,这个开销明显很大。

用户态到内核态的切换,涉及到上下文的切换(context),cpu需要保护现场,在进入内核前需要保存寄存器的状态,在内核返回后还需要从寄存器里恢复状态,这是个不小的开销。

由于传统的轮询方法开销过大,于是IO多路复用复用器出现了,IO多路复用器有select、poll、evport、kqueue、epoll。Redis在I/O多路复用程序的实现源码中用#include宏定义了相应的规则,程序会在编译时自动选择系统中性能最高的I/O多路复用函数库来作为Redis的I/O多路复用程序的底层实现:

// Include the best multiplexing layer supported by this system. The following should be ordered by performances, descending.
# ifdef HAVE_EVPORT
# include "ae_evport.c"
# else
    # ifdef HAVE_EPOLL
    # include "ae_epoll.c"
    # else
        # ifdef HAVE_KQUEUE
        # include "ae_kqueue.c"
        # else
        # include "ae_select.c"
        # endif
    # endif
# endif
 

我们这里主要介绍两种非常经典的复用器select和epoll,select是IO多路复用器的初代,select是如何解决不停地从用户态到内核态的轮询问题的?

select

既然每次轮询很麻烦,那么select就把一批socket的fds集合一次性交给内核,然后内核自己遍历fds,然后判断每个fd的可读可写状态,当某个fd的状态满足时,由用户自己判断去获取。

fds = []int{fd1,fd2,...}
for {
 select (fds)
 for i:= 0; i < len(fds); i++{
  if isReady(fds[i]) {
      read()
     }
  }
}

select的缺点:当一个进程监听多个socket的时候,通过select会把内核中所有的socket的等待队列都加上本进程(多对一),这样当其中一个socket有数据的时候,它就会把告诉cpu,同时把这个进程从阻塞态唤醒,等待被cpu的调度,同时会把进程从所有的socket的等待队列中移除,当cpu运行这个进程的时候,进程因为本身传进去了一批fds集合,我们并不知道哪个fd来数据了,所以只能都遍历一次,这样对于没有数据到来的fd来说,就白白浪费了。由于每次select要遍历socket集合,那么这个socket集合的数量过大就会影响整体效率,这原因也是select为什么支持最大1024个并发的。

epoll

如果有一种方法使得不用遍历所有的socket,当某个socket的消息到来时,只需要触发对应的socket fd,而不用盲目的轮询,那效率是不是会更高。epoll的出现就是为了解决这个问题:

epfd = epoll_create()
epoll_ctl(epfd, fd1, fd2...)
for {
  epoll_wait()
  for fd := range fds {
    doSomething()
  }
}
  • 首先通过epoll_create创建一个epoll对象,它会返回一个fd句柄,和socket的句柄一样,也是管理在fds集合下。
  • 通过epoll_ctl,把需要监听的socket fd和epoll对象绑定。
  • 通过epoll_wait来获取有数据的socket fd,当没有一个socket有数据的时候,那么此处会阻塞,有数据的话,那么就会返回有数据的fds集合。

epoll是怎么做到的?

首先内核的socket不在和用户的进程绑定了,而是和epoll绑定,这样当socket的数据到来时,中断程序就会给epoll的一个就绪对列添加对应socket fd,这个队列里都是有数据的socket,然后和epoll关联的进程也会被唤醒,当cpu运行进程的时候,就可以直接从epoll的就绪队列中获取有事件的socket,执行接下来的读。整个流程下来,可以发现用户程序不用无脑遍历,内核也不用遍历,通过中断做到"谁有数据处理谁"的高效表现。

Redis缓存IO模型的演进教程示例精讲_第3张图片

单线程到多线程的演进

单线程

结合Reactor的思想加上高性能epoll IO模式,redis开发出一套高性能的网络IO架构:单线程的IO多路复用,IO多路复用器负责接受网络IO事件,事件最终以队列的方式排队等待被处理,这是最原始的单线程模型,为什么使用单线程?因为单线程的redis已经可以达到10w qps的负载(如果做一些复杂的集合操作,会降低),满足绝大部分应用场景了,同时单线程不用考虑多线程带来的锁的问题,如果还没达到你的要求,那么你也可以配置分片模式,让不同的节点处理不同的sharding key,这样你的redis server的负载能力就能随着节点的增长而进一步线性增长。

异步线程

在单线程模式下有这样一个问题,当执行删除某个很大的集合或者hash的时候会很耗时(不是连续内存),那么单线程的表现就是其他还在排队的命令就得等待。当等待的命令越来越多,那么不好的事情就会发生。于是redis4.0针对大key删除的情况,出了个异步线程。用unlink代替del去执行删除,这样当我们unlink的时候,redis会检测当删除的key是否需要放到异步线程去执行(比如集合的数量超过64个...),如果value足够大,那么就会放到异步线程里去处理,不会影响主线程。同样的还有flushall、flushdb都支持异步模式。此外redis还支持某些场景下是否需要异步线程来处理的模式(默认是关闭的):

lazyfree-lazy-eviction no
lazyfree-lazy-expire no
lazyfree-lazy-server-del no
replica-lazy-flush no

lazyfree-lazy-eviction:针对redis有设置内存达到maxmemory的淘汰策略时,这时候会启动异步删除,此场景异步删除的缺点就是如果删除不及时,内存不能得到及时释放。

lazyfree-lazy-expire:对于有ttl的key,在被redis清理的时候,不执行同步删除,加入异步线程来删除。

replica-lazy-flush:在slave节点加入进来的时候,会执行flush清空自己的数据,如果flush耗时较久,那么复制缓冲区堆积的数据就越多,后面slave同步数据较相对慢,开启replica-lazy-flush后,slave的flush可以交由异步现成来处理,从而提高同步的速度。

lazyfree-lazy-server-del:这个选项是针对一些指令,比如rename一个字段的时候执行RENAME key newkey, 如果这时newkey是b存在的,对于rename来说它就要删除这个newkey原来的老值,如果这个老值很大,那么就会造成阻塞,当开启了这个选项时也会交给异步线程来操作,这样就不会阻塞主线程了。

多线程

redis单线程+异步线程+分片已经能满足了绝大部分应用,然后没有最好只有更好,redis在6.0还是推出了多线程模式。默认情况下,多线程模式是关闭的。

# io-threads 4 # work线程数
# io-threads-do-reads no # 是否开启

多线程的作用点?

通过上文我们知道当我们从一个socket中读取数据的时候,需要从内核copy到用户空间,当我们往socket中写数据的时候,需要从用户空间copy到内核。redis本身的计算还是很快的,慢的地方那么主要就是socket IO相关操作了。当我们的qps非常大的时候,单线程的redis无法发挥多核cpu的好处,那么通过开启多个线程利用多核cpu来分担IO操作是个不错的选择。

So for instance if you have a four cores boxes, try to use 2 or 3 I/O threads, if you have a 8 cores, try to use 6 threads.

开启的话,官方建议对于一个4核的机器来说,开2-3个IO线程,如果有8核,那么开6个IO线程即可。

多线程的原理

需要注意的是redis的多线程仅仅只是处理socket IO读写是多个线程,真正去运行指令还是一个线程去执行的。

  1. redis server通过EventLoop来监听客户端的请求,当一个请求到来时,主线程并不会立马解析执行,而是把它放到全局读队列clients_pending_read中,并给每个client打上CLIENT_PENDING_READ标识。
  2. 然后主线程通过RR(Round-robin)策略把所有任务分配给I/O线程和主线程自己。
  3. 每个线程(包括主线程和子线程)根据分配到的任务,通过client的CLIENT_PENDING_READ标识只做请求参数的读取和解析(这里并不执行命令)。
  4. 主线程会忙轮询等待所有的IO线程执行完,每个IO线程都会维护一个本地的队列io_threads_list和本地的原子计数器io_threads_pending,线程之间的任务是隔离的,不会重叠,当IO线程完成任务之后,io_threads_pending[index] = 0,当所有的io_threads_pending都是0的时候,就是任务执行完毕之时。
  5. 当所有read执行完毕之后,主线程通过遍历clients_pending_read队列,来执行真正的exec动作。
  6. 在完成命令的读取、解析、执行之后,就要把结果响应给客户端了。主线程会把需要响应的client加入到全局的clients_pending_write队列中。
  7. 主线程遍历clients_pending_write队列,再通过RR(Round-robin)策略把所有任务分给I/O线程和主线程,让它们将数据回写给客户端。

多线程模式下,每个IO线程负责处理自己的队列,不会互相干扰,IO线程要么同时在读,要么同时在写,不会同时读或写。主线程也只会在所有的子线程的任务处理完毕之后,才会尝试再次分配任务。同时最终的命令执行还是由主线程自己来完成,整个过程不涉及到锁。

以上就是Redis线程IO模型的演进教程示例精讲的详细内容,更多关于Redis线程IO模型的演进的资料请关注脚本之家其它相关文章!

你可能感兴趣的:(Redis缓存IO模型的演进教程示例精讲)