目录
面试题
Redis到底是多线程还是单线程？
简单回答
详解
Redis的“单线程”
Redis为什么选择单线程？
后来Redis为什么又逐渐加入了多线程特性？
Redis为什么快？
回答
IO多路复用
Unix网络编程的5种IO模型
主线程和IO线程怎么协作完成请求处理的
四个阶段
浅谈IO多路复用
文件描述符（FileDescriptor, FD）
什么是IO多路复用
场景模拟
总结
Redis 7 默认设置是否开启了多线程？
总结
这篇我们从几个面试题入手
面试题
Redis到底是多线程还是单线程？
简单回答
Redis 是从4开始慢慢支持多线程的，直到 Redis6/7 后才稳定
详解
这种问法其实并不严谨，单线程还是多线程需要视版本而定。
Redis的版本很多3.X、4.X、6.X，版本不同架构也是不同的，不限定版本问是否单线程也不太严谨。
版本3.×（最早版本），也就是大家口口相传的Redis是单线程；
版本4.×，严格意义来说也不是单线程，而是负责处理客户端请求的线程单线程，但是开始加了点多线程的东西（异步删除）；
版本6.x 开始，全面支持多线程。
Redis的“单线程”
Redis的“单线程”主要是指Redis的网络IO和键值对读写是由一个线程来完成的，Redis在处理客户端的请求时包括获取（socket读）、解析、执行、内容返回（socket写）等都由一个顺序串行的主线程处理（第一篇介绍过的那些原子的命令），这也是Redis对外提供键值存储服务的主要流程。
Redis采用Reactor模式的网络模型，对于一个客户端请求，主线程负责一个完整的处理过程，如下图：
补充：
Reactor 模式是一种并发模型，在这种模型中，主线程（Reactor）避免了由于等待一或多个并发事件（比如 I/O 操作）的完成而无法继续工作的阻塞。通过使用非阻塞 I/O 操作和事件通知，主线程在并发操作完成时得到通知。
一般来说，Reactor 模式的工作流程如下：
- 应用程序将需要监听的 I/O 事件（比如 socket 的可读、可写事件）注册到 Reactor 中，并且关联对应的处理事件。
- Reactor 不断地轮询这些事件，当某个事件到达的时候（比如 socket 中有数据可读），Reactor 将这个事件对应的处理事件唤醒，交由一个工作线程（或者称之为 EventHandler）去处理。
- 工作线程处理完相应的事件后，通知 Reactor 继续监听这个事件。
这种模型非常适合于大并发，少逻辑的网络程序中，比如 Nginx 中就用到了这种设计模式。通过这种方式，一个线程可以处理很多连接的事件，而不需要为每个连接都创建一个线程，这样就可以避免线程切换的开销，并且可以更有效地使用系统资源。
但Redis的其他功能，比如持久化RDB、AOF、异步删除、集群同步数据等都是由额外的线程执行的，因此整个Redis可以看作是多线程的。
Redis为什么选择单线程？
准确的说，应该是Redis 4.0之前一直采用单线程
主要原因有：
- 使用单线程模型使Redis的开发和维护更简单
- 虽然使用的是单线程，但也可以并发处理多客户端的请求（IO多路复用和非阻塞IO）
- 对于Redis系统来说，主要的性能瓶颈是内存/网络带宽，而非CPU
后来Redis为什么又逐渐加入了多线程特性？
- 硬件的发展
-
- CPU并不是Redis的瓶颈，通常Redis要不受内存限制要不受网络限制，但是随着计算机硬件的发展，多核CPU已经成为常态，为了更大限度的利用CPU
- 单线程的缺点
-
- Redis使用单线程也是有一定缺点的，比较典型的就是使用del指令删除大key数据时（比如包含了成千上万个元素的hash集合，关于大key的问题我们会在Redis系列的下一篇专门介绍，这里先简单举个例子），del指令就会造成主线程卡顿。
- 由于Redis3.x完全是单线程的，del指令删除时会等待⌛️很久才释放，如果再加上高并发场景(˶‾᷄ ⁻̫ ‾᷅˵)额。。这就是Redis3.x单线程时代最经典的故障，大key删除的头疼问题，于是Redis4.0就新增了多线程模块，也主要是为了解决这个问题。
- 此外例如flushdb还有flushall在数据量达到一定程度时，也会造成卡顿，因此一开始Redis就是把某些时间复杂度高，占主线程CPU时间片较高，造成主线程卡顿的操作使用多线程来处理（bio子线程），以减少主线程阻塞时间，从而减少那个诸如del操作导致性能和稳定性的问题。
总的来说，就是与时俱进(￣∇￣)/🎉～～～
Redis为什么快？
回答
Redis 3.0 单线程时代依旧很快的原因：
- 基于内存操作：Rdis的所有数据都存在内存中，因此所有的运算都是内存级别的，所以他的性能比较高
- 数据结构简单：Rdis的数据结构是专门设计的，而这些简单的数据结构的查找和操作的时间大部分复杂度都是O(1)，因此性能比较高
- 多路复用和非阻塞I/O：Redis使用多路复用功能来监听多个socket连接客户端，这样就可以使用一个线程连接来处理多个请求，减少线程切换带来的
- 避免上下文切换：因为是单线程模型，因此就避免了不必要的上下文切换和多线程竞争，这就省去了多线程切换带来的时间和性能上的消耗，而且单线程
现在Redis快的原因
在上面原因的基础上
- IO多路复用 + epoll函数使用
接下来我们详细介绍下IO多路复用
IO多路复用
IO多路复用（IO multiplexing）是Unix网络编程的5种IO模型之一。
Unix网络编程的5种IO模型
- Blocking IO 阻塞IO
- NoneBlocking IO 非阻塞IO
- IO multiplexing IO 多路复用
- signal driven IO 信号驱动IO
- asynchronous IO 异步IO
Redis一直被大家熟知的就是它的单线程架构，虽然从Redis4.0开始使用了多线程，也是为了处理数据删除、快照删除等耗时操作，从网络IO处理到实际的读写命令处理都是由主线程独自处理的（心疼下主线程）。
在Redis 6/7中，Redis全面支持了多线程。这是由于随着硬件性能的提升，Redis的性能瓶颈主要出现在网络IO上，就是完全靠单个主线程处理网络请求的速度跟不上底层网络硬件的速度，于是采用多个线程处理网络IO，提高网络请求处理的并行度。
但是，Redis的多IO线程只是用来处理网络请求的，对于读写操作命令 Redis 仍然使用单线程来处理。这是因为，Redis处理请求时，网络处理经常是瓶颈，通过多个IO线程并行处理网络操作，可以提升实例的整体处理性能。而继续使用单线程执行命令操作，就不用为了保证Lua脚本、事务的原子性，额外开发多线程互斥加锁机制了（不管加锁操作处理），这样一来，Redis 线程模型实现就简单了。
主线程和IO线程怎么协作完成请求处理的
四个阶段
- 阶段一：服务端和客户端建立Socket连接，并分配处理线程 首先，主线程负责接收建立连接请求，当有客户端请求和实例建立Socket连接时，主线程会创建和客户端的连接，并把Socket放入全局等待队列中，紧接着，主线程通过轮询方法把Socket连接分配给IO线程。
- 阶设二：IO线程读取并解折请求 主线程一旦把Socket分配给IO线程，就会进入阻塞状态，等待IO线程完成客户端请求的读取和解析，因为有多个IO线程在并行处理，所以，这个过程很快就可以完成。
- 阶段三：主线程执行请求操作 等到IO线程解析完请求，主线程还是会以单线程的方式执行这些命令操作。
- 阶设四：IO线程回写Socket和主线程清空全局队列 当主线程执行完请求操作后，会把需要返回的结果写入缓冲区，然后，主线程会阻塞等待IO线程，把这些结果回写到Socket中，并返回给客户端。和IO线程读取和解析请求一样，IO线程回写Socket时，也是有多个线程在并发执行，所以回写Socket的速度也很快。等到IO线程回写Socket完毕，主线程会清空全局队列，等待客户端的后续请求。
浅谈IO多路复用
由于IO多路复用（IO multiplexing）是Unix网络编程的5种IO模型之一，我们先介绍下Linux的相关内容，便于理解（熟悉的人可以直接跳到下一趴）。
在Linux中，一切皆文件，这就要提到“文件描述符”这个概念了。
文件描述符（FileDescriptor, FD）
文件描述符是计算机科学中的一个术语，是一个用于表述指向文件的引用的抽象化概念。
文件描述符在形式上是一个非负整数，实际上它是一个索引值，指向内核为每一个进程所维护的该进程打开文件的记录表。当程序打开一个现有文件或者创建一个新文件时，内核向该进程返回一个文件描述符。
在程序设计中，文件描述符这一概念往往只适用于UNIX或者Linux这样的操作系统。
什么是IO多路复用
一种同步的IO模型，实现一个线程监视多个文件句柄，一旦某个文件句柄就绪，就能通知到对应程序进行相应的读写操作，没有文件句柄就绪时，就会阻塞应用程序，从而释放CPU资源。
我们来介绍几个概念：
- I/O
-
- 网络I/O，尤其在操作系统层面指数据在内核态和用户态之间的读写操作
- 多路
-
- 多个客户端连接（连接就是套接字描述符，即socket或者channel）
- 复用
-
- 复用一个或者几个线程连接
- IO多路复用
-
- 也就是说一个或者一组线程处理多个TCP，使用单进程就能实现同时处理多个客户端的连接，无需创建或者维护过多的进程/线程
总结
- 一个服务端进程可以同时处理多个套接字描述符
- 实现多路复用的模型有3种：可以分select->poll->epoll3个阶段来描述
场景模拟
不知道大家有没有注意过麻辣烫店是怎么做煮麻辣烫的，他们可不是一碗一碗单独的锅单独的灶煮的（太费💰），一般是有一个方形大锅，整个锅里加满水，下面一个灶加热，大锅里分成一个个小格子（就类似重庆火锅那种九宫格），每个小格子里煮一个客人选的菜。
基本流程就是，客人选完菜去收银那里称斤付款（人多则需要排队），服务员每收到一个客人选的菜，就把它们倒进一个小格子里煮，然后再回来收下一位的……还会时不时看看哪个小格子里的菜熟了，就把它盛到碗里，端回给客人
我们根据模拟情景来简单概括下IO多路复用模型：
将用户Socket对应的文件描述符（FileDescriptor）注册进epoll，然后epoll帮你监听哪些Socket上有消息到达，这样就避免了大量的无用操作，此时的Socket应该采用非阻塞模式，这样整个过程只在调用select、poll、epoll这些函数是才会阻塞，收发客户消息是不会阻塞的，整个进程/线程就会被充分利用起来，这就是事件驱动，所谓的reactor反应模式。
在单个线程通过记录跟踪每一个Socket（I/O流）的状态来同时管理多个I/O流，一个服务端进程可以同时处理多个套接字描述符，以此来提高服务器的吞吐能力。
大家都用过nginx，nginx使用epoll接收请求，ngnix会有很多链接进来，epoll会把他们都监视起来，然后像拨开关一样，谁有数据就拨向谁，然后调用相应的代码处理。Redis类似同理，这就是IO多路复用原理，有请求就响应，没请求不打扰。
IO多路复用达到的效果就是只使用一个服务端进程可以同时处理多个套接字描述符连接。
客户端请求服务端时，实际就是在服务端的Socket文件中写入客户端对应的文件描述符（FileDescriptor），如果有多个客户端同时请求服务端，为每次请求分配一个线程，类似每次来就new一个太耗费服务端资源，因此，只使用一个线程来监听多个文件描述符，即IO多路复用。
采用IO多路复用技术可以让单个线程高效的处理多个连接请求，一个服务端进程可以同时处理多个套接字描述符。
从Rdis6开始，就新增了多线程的功能来提高I/O的读写性能，他的主要实现思路是将主线程的IO读写任务拆分给一组独立的线程去执行，这样就可以使多个Socket的读写可以并行化了，采用多路I/O复用技术可以让单个线程高效的处理多个连接请求（尽量减少网络IO的时间消耗)，将最耗时的Socket的读取、请求解析、写入单独外包出去，剩下的命令执行仍然由主线程串行执行并和内存的数据交互。
于是，网络IO操作就变成多线程了，其他核心操作仍然是主线程单独处理（线程安全）
总结
- Redis的工作线程是单线程的，但是整个Redis是多线程的
- Redis6/7将网络数据读写、请求协议解析通过多个IO线程来处理，真正执行命令的线程仍然是主线程单独进行操作（单线程），一举两得，既解决网络IO问题（多个IO线程），有保证了线程安全且处理方式简单（单线程执行命令）
Redis 7 默认设置是否开启了多线程？
如果你在实际应用中，发现Redis实例的CPU开销不大但吞吐量却没有提升，可以考虑使用Reds7的多线程机制（默认关闭，需手动开启），加速网络处理，进而提升实例的吞吐量。
Redis7将所有的数据放在内存中，内存的响应时长大约为100纳秒，对于小数据，Redis服务器可以处理8W到10W的QPS（实验室数据，极限），但是对于大部分的公司已经够用了，所以在Redis6.0以后，多线程机制默认是关闭的，如果需要使用，则要在redis.conf配置文件中修改，主要改两个地方：文章来源：https://www.toymoban.com/news/detail-610540.html
- 设置io-threads-do-redis配置项为yes，表示启动多线程
- 设置线程个数，io-threads 个数，关于个数的设置，官方的建议是如果为4核的CPU，建议线程数设置为2或3，如果为8核CPU建议线程数设置为6（线程数一定要小于机器核数，并非越大越好）
总结
Redis基于内存操作、数据结构简单、多路复用和非阻塞I/O等特性，避免了不必要的上下文切换，在单线程的环境下依旧很快。但对于大数据的key删除还是会卡顿，因此在4.0版本中引入了多线程unlink key/flushall async等命令，主要用于Redis数据的异步删除。而在Redis6/7中引入了I/O多线程的读写，增加了吞吐量，而命令的执行依旧是有主线程串行执行的，因此在多线程下操作Redis既能保持良好的性能和响应速度，并且不会出现线程安全的问题。文章来源地址https://www.toymoban.com/news/detail-610540.html
到了这里，关于【Redis】高级篇： 一篇文章讲清楚Redis的单线程和多线程的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
