Redis是多线程还是单线程？

文章目录

1、用户态和内核态
2、阻塞IO
3、非阻塞IO
4、IO多路复用
- 4.1 select
- 4.2 poll
- 4.3 epoll
- 4.4 epoll中的ET和LT
- 4.5 epoll的服务端流程
5、信号驱动
6、异步IO
7、对比
8、Redis是单线程的吗？
9、单线程多线程网络模型变更

1、用户态和内核态

1、ubuntu和Centos 都是Linux的发行版，发行版可以看成对linux包了一层壳，任何Linux发行版，其系统内核都是Linux。我们的应用都需要通过Linux内核与硬件交互

2、计算机硬件包括，如cpu，内存，网卡等等，内核（通过寻址空间）可以操作硬件的，但是内核需要不同设备的驱动，有了这些驱动之后，内核就可以去对计算机硬件去进行内存管理，文件系统的管理，进程的管理等等。

3、我们想要用户的应用来访问，计算机就必须要通过对外暴露的一些接口，才能访问到，从而实现对内核的操控，但是内核本身上来说也是一个应用，所以他本身也需要一些内存，cpu等设备资源，用户应用本身也在消耗这些资源，如果不加任何限制，用户去随意的操作我们的资源，就有可能导致一些冲突，甚至有可能导致我们的系统出现无法运行的问题，因此我们需要把用户和内核隔离开

4、进程的寻址空间划分成两部分：内核空间、用户空间。我们的应用程序也好，还是内核空间也好，都是没有办法直接去物理内存的，而是通过分配一些虚拟内存映射到物理内存中，我们的内核和应用程序去访问虚拟内存的时候，就需要一个虚拟地址，这个地址是一个无符号的整数，比如一个32位的操作系统，他的带宽就是32，他的虚拟地址就是2的32次方，也就是说他寻址的范围就是0~2^32，这片寻址空间对应的就是2^32个字节，就是4GB，这个4GB，会有3个GB分给用户空间，会有1GB给内核系统

在linux中，权限分成两个等级，0和3，用户空间只能执行受限的命令（Ring3），而且不能直接调用系统资源，必须通过内核提供的接口来访问

内核空间可以执行特权命令（Ring0），调用一切系统资源，所以一般情况下，用户的操作是运行在用户空间，而内核运行的数据是在内核空间的，而有的情况下，一个应用程序需要去调用一些特权资源，去调用一些内核空间的操作，所以此时他俩需要在用户态和内核态之间进行切换。

比如：

Linux系统为了提高IO效率，会在用户空间和内核空间都加入缓冲区：

写数据时，要把用户缓冲数据拷贝到内核缓冲区，然后写入设备
读数据时，要从设备读取数据到内核缓冲区，然后拷贝到用户缓冲区

针对这个操作：用户在写读数据时，会去向内核态申请，想要读取内核的数据，而内核数据要去等待驱动程序从硬件上读取数据，当从磁盘上加载到数据之后，内核会将数据写入到内核的缓冲区中，然后再将数据拷贝到用户态的buffer中，然后再返回给应用程序，整体而言，速度慢，就是这个原因，为了加速，我们希望read也好，还是wait for data，最好都不要等待，或者时间尽量的短。

5种IO模型：

阻塞IO（Blocking IO）
非阻塞IO（Nonblocking IO）
IO多路复用（IO Multiplexing）
信号驱动IO（Signal Driven IO）
异步IO（Asynchronous IO）

2、阻塞IO

应用程序想要去读取数据，他是无法直接去读取磁盘数据的，他需要先到内核里边去等待内核操作硬件拿到数据，这个过程就是1，是需要等待的。等到内核从磁盘上把数据加载出来之后，再把这个数据写给用户的缓存区，这个过程是2，如果是阻塞IO，那么整个过程中，用户从发起读请求开始，一直到读取到数据，都是一个阻塞状态。

阻塞IO流程

用户去读取数据时，会去先发起recvform一个命令，去尝试从内核上加载数据，如果内核没有数据，那么用户就会等待，此时内核会去从硬件上读取数据，内核读取数据之后，会把数据拷贝到用户态，并且返回ok，整个过程，都是阻塞等待的，这就是阻塞IO

阶段一

用户进程尝试读取数据（比如网卡数据）
此时数据尚未到达，内核需要等待数据
此时用户进程也处于阻塞状态

阶段二

数据到达并拷贝到内核缓冲区，代表已就绪
将内核数据拷贝到用户缓冲区
拷贝过程中，用户进程依然阻塞等待
拷贝完成，用户进程解除阻塞，处理数据

阻塞IO模型中，用户进程在两个阶段都是阻塞状态。

3、非阻塞IO

非阻塞IO的recvfrom操作会立即返回结果而不是阻塞用户进程。

阶段一：

用户进程尝试读取数据（比如网卡数据）
此时数据尚未到达，内核需要等待数据
返回异常给用户进程
用户进程拿到error后，再次尝试读取
循环往复，直到数据就绪

阶段二：

将内核数据拷贝到用户缓冲区
拷贝过程中，用户进程依然阻塞等待
拷贝完成，用户进程解除阻塞，处理数据

非阻塞IO模型中，用户进程在第一个阶段是非阻塞，第二个阶段是阻塞状态。虽然是非阻塞，但性能并没有得到提高。而且忙等机制会导致CPU空转，CPU使用率暴增。

4、IO多路复用

无论是阻塞IO还是非阻塞IO，用户应用在一阶段都需要调用recvfrom来获取数据

如果调用recvfrom时，恰好没有数据，阻塞IO会使CPU阻塞，非阻塞IO使CPU空转，都不能充分发挥CPU的作用。
如果调用recvfrom时，恰好有数据，则用户进程可以直接进入第二阶段，读取并处理数据

在单线程情况下，只能依次处理IO事件，如果正在处理的IO事件恰好未就绪（数据不可读或不可写），线程就会被阻塞，所有IO事件都需要等待，性能会很差。

IO多路复用就是，哪个socket的数据准备好了，那么我就去读取对应数据

文件描述符（File Descriptor）：简称FD，是一个从0 开始的无符号整数，用来关联Linux中的一个文件。在Linux中，一切皆文件，例如常规文件、视频、硬件设备等，当然也包括网络套接字（Socket）。

通过FD，我们的网络模型可以利用一个线程监听多个FD，并在某个FD可读、可写时得到通知，从而避免无效的等待，充分利用CPU资源。

阶段一：

用户进程调用select，指定要监听的FD集合
内核监听FD对应的多个socket
任意一个或多个socket数据就绪则返回readable
此过程中用户进程阻塞

阶段二：

用户进程找到就绪的socket
依次调用recvfrom读取数据
内核将数据拷贝到用户空间
用户进程处理数据

当用户去读取数据的时候，不再去直接调用recvfrom了，而是调用select函数，select函数会将需要监听的数据交给内核，由内核去检查这些数据是否就绪了，如果说这个数据就绪了，就会通知应用程序数据就绪，然后来读取数据，再从内核中把数据拷贝给用户态，完成数据处理，如果N多个FD一个都没处理完，此时就进行等待。

用IO多路复用模式，可以确保去读数据的时候，数据是一定存在的，他的效率比原来的阻塞IO和非阻塞IO性能都要高

IO多路复用是利用单个线程来同时监听多个FD，并在某个FD可读、可写时得到通知，从而避免无效的等待，充分利用CPU资源。不过监听FD的方式、通知的方式又有多种实现，常见的有：

select
poll
epoll

select和pool相当于是当被监听的数据准备好之后，他会把你监听的FD整个数据都发给你，你需要到整个FD中去找，哪些是处理好了的，需要通过遍历的方式，所以性能也并不是那么好。而epoll，则相当于内核准备好了之后，他会把准备好的数据，直接发给你，省去了遍历的动作。

4.1 select

我们把需要处理的数据封装成FD，然后在用户态创建一个fd的集合（这个集合的大小是要监听的那个FD的最大值+1，但是大小整体是有限制的），这个集合的长度大小是有限制的，同时在这个集合中，标明出来我们要监控哪些数据，

下面是select的源码，其中fd_set是要监听的fd集合，是一个大小为32的数组，而数组元素是__fd_mask类型的，__fd_mask是32位大小，因此fd_set数组大小为32，但是可以表示1024个bit位，一个bit位就代表一个fd，因此最多可以存储1024的fd

执行流程

1、创建fd_set，大小为1024bit

2、假如要监听的数据是1，2，5，将1，2，5三个数据的位置置位1，然后执行select函数，同时将整个fd发给内核态

3、内核态会去遍历用户态传递过来的数据，如果发现这里边的数据都没有就绪，就休眠，直到有数据准备好时，就会被唤醒，唤醒之后，再次遍历一遍，看看谁准备好了，然后处理掉没准备好的数据，最后再将这个FD集合写回到用户态中去，返回就绪的数量

4、此时用户态就知道有数据准备好了，但是对于用户态而言，并不知道谁处理好了，所以用户态也需要去进行遍历，然后找到对应准备好数据的节点，再去发起读请求。

5、继续执行步骤2，使用select监听未准备好的数据

select模式缺点

需要将整个fd_set从用户空间拷贝到内核空间，select结束还要再次拷贝回用户空间
select无法得知哪个fd准备好了，需要遍历整个fd_set
fd_set监听的fd数量不能超过1024

4.2 poll

poll模式对select模式做了简单改进，但性能提升不明显。

调用poll函数时，需要创建多个pollfd结构体，形成数组传进去，此时pollfd只需指定fd和events，内核监听到数据后，将发生的事件传入revents中，然后拷贝给用户空间，如果poll超时未监听到数据就绪，就将revents置位0，表示没有事件发生

IO流程：

创建pollfd数组，向其中添加监听的fd信息，数组大小自定义
调用poll函数，将pollfd数组拷贝到内核空间，转链表存储，无上限
内核遍历pollfd数组，判断是否就绪
数据就绪或超时后，拷贝pollfd数组到用户空间，返回就绪fd数量n
用户进程判断n是否大于0，大于0则遍历pollfd数组，找到就绪的fd

与select对比

select模式中的fd_set大小固定为1024，而pollfd在内核中采用链表，理论上无上限
监听FD越多，每次遍历消耗时间也越久，性能反而会下降

4.3 epoll

epoll模式是对select和poll的改进

1、eventpoll：内部包含两个元素

红黑树：记录要监听的FD
链表：记录就绪的FD

2、epoll_create：调用该函数，会在内核中创建eventpoll的结构体，返回对应的句柄

3、紧接着调用epoll_ctl操作，将要监听的数据添加到红黑树上去，并且给每个fd设置一个ep_poll_callback，这个函数会在fd数据就绪时触发，数据准备好了，就将fd的数据添加到list_head中去

4、调用epoll_wait函数等待，在用户态创建一个空的events数组，当就绪之后，我们的回调函数会把数据添加到list_head中去，当调用这个函数的时候，会去检查list_head，这个过程需要参考配置的等待时间，可以等一定时间，也可以一直等，如果在此过程中，检查到了list_head中有数据会将数据添加到链表中，此时将数据放入到events数组中，并且返回对应的操作的数量，用户态此时收到响应后，从events中拿到对应准备好的数据的节点，再去调用方法去拿数据。

select模式存在的三个问题

能监听的FD数量最大不超过1024
每次select都需要把所有要监听的FD都拷贝到内核空间，同时内核态监听到数据就绪后，需要将所有的FD拷贝回用户空间
每次都要遍历所有FD来判断就绪状态。当数据就绪后，内核态需要遍历所有的FD，以判断是哪个FD就绪，然后将所有FD拷贝回用户空间

poll模式的问题

poll利用链表解决了select中监听FD上限的问题，但依然要遍历所有FD，如果监听较多，性能会下降

epoll模式

基于epoll实例中的红黑树保存要监听的FD，理论上无上限，而且增删改查效率都非常高
每个FD只需要执行一次epoll_ctl添加到红黑树，以后每次epol_wait无需传递任何参数，无需重复拷贝FD到内核空间。不用像select那样，每次都需要将需要监听的FD拷贝到内核空间
利用ep_poll_callback机制来监听FD状态，只要数据就绪，就将对应的FD放入list_head，无需遍历所有FD，因此性能不会随监听的FD数量增多而下降
调用epoll_wait时，将就绪的FD拷贝到用户空间的events中，每次只拷贝就绪的FD，不像select一样拷贝所有FD

4.4 epoll中的ET和LT

当FD有数据可读时，我们调用epoll_wait（或者select、poll）可以得到通知。事件通知的模式有两种：

EdgeTriggered：简称ET，也叫做边沿触发。只有在某个FD有状态变化时，调用epoll_wait才会被通知。
LevelTriggered：简称LT，也叫做水平触发。只要某个FD中有数据可读，每次调用epoll_wait都会得到通知。

例如：

1、假设一个客户端socket对应的FD已经注册到了epoll实例中

2、客户端socket发送了2kb的数据

3、服务端调用epoll_wait，得到通知FD就绪

4、服务端从FD读取了1kb数据

5、回到步骤3（再次调用epoll_wait，形成循环）

如果是LT模式，重复调用epoll_wait都会得到通知，如果是ET模式，只有第一次调用epoll_wait才会得到通知

调用epoll_wait在数据拷贝之前，会将数据从链表中断开，然后完成拷贝的动作。之后根据不同的模式执行不同操作

ET：直接将数据从链表删除，因此再次调用epoll_wait就不会通知，如果第一次没有读取完数据，下次在读就读取不到残留数据

解决方法：
- 调用epoll_wait后，FD中还有数据，手动将FD添加到就绪列表中，调用epoll_ctl函数，修改FD上的状态，发现FD上还有就绪的数据，就会重新添加回就绪队列
- 循环读取，一次性读取全部数据。注意：不能使用阻塞IO，使用阻塞IO如果读到FD中没有数据了，他会阻塞在这里等待，导致进行阻塞
LT：如果发现数据还未读取完成，会重新将就绪的数据添加回链表，因此再次调用epoll_wait还会收到通知

LT产生的问题：
- 重复通知，效率有影响
- 可能出现惊群现象：假设有n个进程同时监听同一个FD，调用epoll_wait读取数据，数据就绪后，这些进程都会被通知到可以读取数据，可能前一两个进程就将数据读取完毕，所以后续这些进程就没有必要去读取

4.5 epoll的服务端流程

1、服务器启动以后，服务端会去调用epoll_create，创建一个epoll实例，epoll实例中包含两个数据

红黑树（为空）：rb_root 用来去记录需要被监听的FD
链表（为空）：list_head，用来存放已经就绪的FD

2、创建好了之后，会去调用epoll_ctl函数，此函数会将需要监听的数据添加到rb_root中去，并且对当前这些存在于红黑树的节点设置回调函数，当这些被监听的数据一旦准备完成，就会被调用，而调用的结果就是将红黑树的fd添加到list_head中去(但是此时并没有完成)

3、当第二步完成后，就会调用epoll_wait函数，这个函数会去校验是否有数据准备完毕（因为数据一旦准备就绪，就会被回调函数添加到list_head中），在等待了一段时间后(可以进行配置)，没有FD就绪，就再次调用epoll_wait。如果有FD就绪，则进一步判断当前是什么事件，如果是建立连接事件，则调用accept() 接受客户端socket，拿到建立连接的socket，然后建立起来连接，同时将其FD注册到epoll中。如果是其他事件，则进行数据读写

5、信号驱动

信号驱动IO是与内核建立SIGIO的信号关联并设置回调，当内核有FD就绪时，会发出SIGIO信号通知用户，期间用户应用可以执行其它业务，无需阻塞等待。

阶段一：

用户进程调用sigaction，注册信号处理函数
内核返回成功，开始监听FD
用户进程不阻塞等待，可以执行其它业务
当内核数据就绪后，回调用户进程的SIGIO处理函数

阶段二：

收到SIGIO回调信号
调用recvfrom，读取
内核将数据拷贝到用户空间
用户进程处理数据

缺点

当有大量IO操作时，信号较多，SIGIO处理函数不能及时处理可能导致信号队列溢出，而且内核空间与用户空间的频繁信号交互性能也较低。

6、异步IO

这种方式，用户态在试图读取数据后，不阻塞，当内核的数据准备完成后，也不会阻塞

他会由内核将所有数据处理完成后，由内核将数据写入到用户态中，然后才算完成，所以性能极高，不会有任何阻塞，全部都由内核完成，异步IO模型中，用户进程在两个阶段都是非阻塞状态。

缺点

用户进程调用aio_read后，去执行新的用户请求，新的用户请求又要调用aio_read去通知内核进行数据的拷贝，高并发情况下，内核积累的IO任务会很多，导致系统占用内存过多导致系统崩溃，所以使用异步IO必须做好对并发访问的限流，实现比较复杂

7、对比

8、Redis是单线程的吗？

Redis是单线程还是多线程？

如果仅仅聊Redis的核心业务部分（命令处理），答案是单线程
如果是聊整个Redis，那么答案就是多线程

在Redis版本迭代过程中，在两个重要的时间节点上引入了多线程的支持：

Redis v4.0：引入多线程异步处理一些耗时较久的任务，例如异步删除命令unlink
Redis v6.0：在核心网络模型中引入多线程，进一步提高对于多核CPU的利用率

因此，对于Redis的核心网络模型，在Redis 6.0之前确实都是单线程。是利用epoll（Linux系统）这样的IO多路复用技术在事件循环中不断处理客户端情况。

为什么Redis要选择单线程？

Redis是纯内存操作，执行速度非常快，它的性能瓶颈是网络延迟而不是执行速度，因此多线程并不会带来巨大的性能提升。
多线程会导致过多的上下文切换，带来不必要的开销
引入多线程会面临线程安全问题，必然要引入线程锁这样的安全手段，实现复杂度增高，而且性能也会大打折扣

9、单线程多线程网络模型变更

Redis通过IO多路复用来提高网络性能，并且支持各种不同的多路复用实现，并且将这些实现进行封装，提供了统一的高性能事件库API库 AE，下边就是Redis对epoll、poll、select等操作使用统一API的封装

aeApiCreate：创建多路复用程序，例如epoll_create
aeApiAddEvent：注册FD，例如epoll_ctl
aeApiPoll：等待FD就绪，比如epoll_wait、select、poll

在ae.c文件中，通过不同的模式导入不同的文件，这样调用API时就是执行的对应模式的操作

#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

Redis单线程网络模型流程

1、main函数中首先执行initServer()初始化服务

调用aeCreateEventLoop()方法创建epoll实例，类似于epoll_create
listenToPort()方法，监听TCP端口，创建ServerSocker，得到FD
将这个FD注册到epoll实例中，然后绑定一个acceptTcpHandler用于处理当前FD【redis服务端】的客户端连接请求
- acceptTcpHandler是用来处理Redis客户端连接请求，首先接收当前socket的连接，得到FD，然后创建connection关联这个FD
- 执行connSetReadHandler，首先将当前这个FD注册到epoll实例中，绑定readQueryFromClient方法处理客户端的读请求
通过aeSetBeforeSleepProc注册aeApiPoll方法前的处理器

2、执行aeMain方法开始监听事件循环

循环监听事件，执行aeProcessEvents方法
- 调用前置处理器beforeSleep
- 调用aeApiPoll方法，返回FD就绪的数量
- 遍历所有就绪的FD，调用对应的处理器，初始时，这里就绪的FD就只有我们的Redis服务端，他收到数据一定是Redis客户端的连接请求，他会执行acceptTcpHandler方法处理这个请求

3、监听到数据后，如果是客户端的连接请求，那么执行acceptTcpHandler方法，将FD注册到epoll实例，同时通过readQueryFromClient方法绑定读处理器

readQueryFromClient方法中，首先获取当前客户端，然后将请求的数据读取到c->querybuf缓冲区中，此时缓冲区中的数据是各种redis命令组成的，然后解析缓冲区中的数据，将其转为Redis命令，存入c->argv数组，例如set name xrj，最后通过processCommand方法执行该命令
processCommand中，首先通过命令名称即c->argv[0]查找对应的command，Redis中将各种命令都映射为xxCommand，然后通过c->cmd->proc(c)执行命令，并得到返回结果，最后一步就是将返回结果写回客户端
addReply方法中先将结果写到缓冲区中，然后将客户端添加到server.clients_pending_write这个队列中，最后写回客户端的操作是由之前aeSetBeforeSleepProc方法执行