redis面试：redis是单线程的，为什么还那么快

深藏阁楼爱情的钟 2022-08-28 07:46 187阅读 0赞

### 文章目录 ###

*  回答
 *  详细解析
 *   *  纯内存操作
     *  redis为什么使用单线程
     *   *  多线程的弊端
         *  单线程的好处
         *  单线程是否没有充分利用 CPU 资源呢？
     *  IO多路复用
     *   *  为什么redis要使用IO多路复用
         *  阻塞IO与非阻塞IO
         *  什么是IO多路复用
         *  阻塞IO VS IO多路复用
         *  事件处理机制
         *  Reactor设计模式
         *  IO多路复用模块
         *  定时任务
 *  参考

# 回答 #

*  完全基于内存，没有磁盘IO上的开销
 *  整个redis本质就是一个全局hash表，它的时间复杂度是O(1)，而且为了防止hash冲突导致链表过长，redis会执行rehash操作，扩充hash同数量，减少hash冲突。并且防止一次性重新映射数据过大导致线程阻塞，采用了渐进式rehash。巧妙的将一次性拷贝分摊到多次请求过程后总，避免阻塞。
 *  底层多种数据结构支持不同的数据类型，支持 Redis 存储不同的数据，这些不同的数据结构，对数据存储进行了优化，比如压缩表；对短数据进行压缩存储，再如，跳表，使用有序的数据结构加快读取的速度；不同数据结构的设计，使得数据存储时间复杂度降到最低。
 *  采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗CPU，不必去考虑各种锁的问题
 *  使用异步非阻塞的多路复用IO，在poll、epoll、kqueue中选择最优实现

# 详细解析 #

## 纯内存操作 ##

我们都知道redis是使用内存来进行数据的存储，这也是为什么redis的访问速度要远远快于mysql的主要原因，因为是使用内存存储数据，可以避免频繁的进行写盘操作，大大降低响应时间：

**磁盘调用栈图**  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_10_color_FFFFFF_t_70_g_se_x_16]  
**内存操作**：内存直接由CPU控制，也就是CPU内部集成的内存控制器，所以说内存是直接与CPU对接，享受与CPU通信的最优带宽。Redis将数据存储在内存中，读写速度不会因为磁盘的IO速度限制。

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_20_color_FFFFFF_t_70_g_se_x_16]

> 高效的速度结构

Redis支持的几种高效的数据结构 string（字符串）、hash（哈希）、list（列表）、set（集合）、zset（有序集合）以上几种对外暴露的数据结构它们的底层编码方式都是做了不同的优化的。

（1）那为什么要提供这么多的数据结构呢？

当然是为了追求速度，不同数据类型使用不同的数据结构速度才得以提升。每种数据类型都有一种或者多种数据结构来支撑，底层数据结构有 6 种。

*  String的底层是（简单动态字符串）
 *  List的底层是（双向链表和压缩链表）
 *  Hash的底层是（压缩链表和哈希表）
 *  Set的底层是（整数数组和哈希表）
 *  Sorted Set底层（压缩链表和跳表）  
    ![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_20_color_FFFFFF_t_70_g_se_x_16 1]  
    （2）redis本质就是一个hash表

redis整体就是一个hash表来保存所有的键值对。hash表，本质就是一个数组，每个元素被叫做hash桶，不管是什么数据类型，每个桶里面的entry保存着实际具体值的指针

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_18_color_FFFFFF_t_70_g_se_x_16]  
整个数据库就是一个**全局hash表**，而hash表的时间复杂度就是O(1)，只需要计算每个键的hash值，就知道对应的hash桶的位置，定位桶里面的entry找到对应数据，这个也是redis块的原因之一。

（3） hash冲突怎么办

当写入1redis的数据越来越多的时候，hash冲突不可避免，会出现不同的key计算出一样的hash值

redis使用链式hash解决冲突，也就是**同一个桶里面的元素使用链表保存**。

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_16_color_FFFFFF_t_70_g_se_x_16]

所以当一个哈希桶下面挂了太多的数据的时候，那么其性能就会下降，为了解决hash碰撞的问题，就需要进行rehash，将我们的哈希桶位置增多，但是在rehash的过程中，需要进行大量的数据移动复制，那在rehash的时候肯定会影响我们的性能

所以redis为了追求块，使用了两个全局hash表。开始默认使用hash表1来保存键值对数据，hash表2此刻没有分配空间。当数据越来越多触发rehash操作，则执行下面操作：

*  给hash表2分配更大的空间
 *  将hash表1的数据重新映射到hash表2中
 *  释放hash表1的空间

值得注意的是，将hash表1的数据重新映射到hash表2的过程并不是一次性的，这样会造成redis阻塞，无法提供服务。

而是采用了渐进式rehash，每次处理客户端请求的时候，先从hash表1中第一个索引开始，将这个位置的所有数据拷贝到hash表2中，就这样将rehash分散到多次请求过程中，避免出现耗时阻塞

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_18_color_FFFFFF_t_70_g_se_x_16 1]

（4） 关于SDS简单动态字符

问题：redis是用C语言实现的，为啥还有搞一个SDS动态字符串呢

回答：

*  字符串结构使用最官方，通常用于我们缓存登录后的用户信息，key = userId，value = 用户信息 JSON 序列化成字符串。
 *  C 语言中字符串的获取 「MageByte」的长度，要从头开始遍历，直到 「\\0」为止，Redis 作为唯快不破的男人是不能忍受的。
 *  C 语言字符串结构与 SDS 字符串结构对比图如下所示：

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_18_color_FFFFFF_t_70_g_se_x_16 2]  
从上面可以看出，SDS与C字符串区别

*  O(1)时间复杂度获取字符串长度
    
     *  C语言需要遍历到’\\0’时结束，时间复杂度为O(N)
     *  SDS中len保存当前字符串长度，时间复杂度为O(1)
 *  **空间预分配**
    
     *  SDS被修改后，程序不仅会为SDS分配所需要的必须空间，还会分配额外的未使用空间
     *  分配规则如下：如果对SDS修改后，len的长度小于1M，那么程序将分配和len相同长度的未使用空间
     *  举个例子，如果 len=10，重新分配后，buf 的实际长度会变为 10(已使用空间)+10(额外空间)+1(空字符)=21。如果对 SDS 修改后 len 长度大于 1M，那么程序将分配 1M 的未使用空间。
 *  **惰性空间释放**
    
     *  当对SDS进行缩短操作时，程序并不会回收多余的内存空间，而是使用free字段将这些字节数量记录下来不释放
     *  后面如果需要使用append操作，则直接使用free中未使用的空间，减少了内存的分配
 *  **二进制安全**
    
     *  你已经知道了 Redis 可以存储各种数据类型，那么二进制数据肯定也不例外。但二进制数据并不是规则的字符串格式，可能会包含一些特殊的字符，比如 ‘\\0’ 等。
     *  前面我们提到过，C 中字符串遇到 ‘\\0’ 会结束，那 ‘\\0’ 之后的数据就读取不上了。但在 SDS 中，是根据 len 长度来判断字符串结束的。
     *  看，二进制安全的问题就解决了。

(5） 双端链表

列表 List 更多是被当作队列或栈来使用的。队列和栈的特性一个先进先出，一个先进后出。双端链表很好的支持了这些特性。  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_18_color_FFFFFF_t_70_g_se_x_16 3]

*  **前后节点**：链表里每个节点都带有两个指针，prev 指向前节点，next 指向后节点。这样在时间复杂度为 O(1) 内就能获取到前后节点。  
    ![在这里插入图片描述][1d0eb34075b94fff8165fc692bf65f27.png]
 *  **头尾节点**：头节点里有 head 和 tail 两个参数，分别指向头节点和尾节点。这样的设计能够对双端节点的处理时间复杂度降至 O(1) ，对于队列和栈来说再适合不过。同时链表迭代时从两端都可以进行。  
    ![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_18_color_FFFFFF_t_70_g_se_x_16 4]
 *  链表长度：头节点里同时还有一个参数 len，和上边提到的 SDS 里类似，这里是用来记录链表长度的。因此获取链表长度时不用再遍历整个链表，直接拿到 len 值就可以了，这个时间复杂度是 O(1)。

你看，这些特性都降低了 List 使用时的时间开销。

(6) zipList 压缩列表

引入：

*  双端链表我们已经熟悉了。但是有一个问题：如果在一个链表节点中存储一个小数据，比如一个字节。那么对应的就要保存头节点，前后指针等额外的数据。
 *  这样就浪费了空间，同时由于反复申请与释放也容易导致内存碎片化。这样内存的使用效率就太低了。
 *  于是，压缩列表上场了！

压缩列表是 List 、hash、 sorted Set 三种数据类型底层实现之一。

当一个列表只有少量数据的时候，并且每个列表项要么就是小整数值，要么就是长度比较短的字符串，那么 Redis 就会使用压缩列表来做列表键的底层实现。

*  ziplist 是由一系列特殊编码的连续内存块组成的顺序型的数据结构，ziplist 中可以包含多个 entry 节点，每个节点可以存放整数或者字符串
 *  ziplist 在表头有三个字段 zlbytes、zltail 和 zllen，分别表示列表占用字节数、列表尾的偏移量和列表中的 entry 个数；压缩列表在表尾还有一个 zlend，表示列表结束。

struct ziplist<T> {
        
        int32 zlbytes; // 整个压缩列表占用字节数
        int32 zltail_offset; // 最后一个元素距离压缩列表起始位置的偏移量，用于快速定位到最后一个节点
        int16 zllength; // 元素个数
        T[] entries; // 元素内容列表，挨个挨个紧凑存储
        int8 zlend; // 标志压缩列表的结束，值恒为 0xFF
    }

如果我们要查找定位第一个元素和最后一个元素，可以通过表头三个字段的长度直接定位，复杂度是 O(1)。而查找其他元素时，就没有这么高效了，只能逐个查找，此时的复杂度就是 O(N)  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_20_color_FFFFFF_t_70_g_se_x_16 2]

*  它是经过特殊编码，专门为了提升内存使用效率设计的。所有的操作都是通过指针与解码出来的偏移量进行的。
 *  并且压缩列表的内存是连续分配的，遍历的速度很快。

后续版本对列表数据结构进行了改造，使用 quicklist 代替了 ziplist 和 linkedlist。

quicklist 是 ziplist 和 linkedlist 的混合体，它将 linkedlist 按段切分，每一段使用 ziplist 来紧凑存储，多个 ziplist 之间使用双向指针串接起来。

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_20_color_FFFFFF_t_70_g_se_x_16 3]

（7）跳跃表

sorted set 类型的排序功能便是通过「跳跃列表」数据结构来实现。

跳跃表（skiplist）是一种有序数据结构，它通过在每个节点中维持多个指向其他节点的指针，从而达到快速访问节点的目的

跳跃表支持平均 O（logN）、最坏 O（N）复杂度的节点查找，还可以通过顺序性操作来批量处理节点。

跳表在链表的基础上，增加了多层级索引，通过索引位置的几个跳转，实现数据的快速定位，如下图所示：  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_20_color_FFFFFF_t_70_g_se_x_16 4]  
这是跳跃表的简单原理图，每一层都有一条有序的链表，最底层的链表包含了所有的元素。这样跳跃表就可以支持在 O(logN) 的时间复杂度里查找到对应的节点。

下面这张是跳表真实的存储结构，和其它数据结构一样，都在头节点里记录了相应的信息，减少了一些不必要的系统开销。

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_18_color_FFFFFF_t_70_g_se_x_16 5]  
（8）合理的数据编码

对于每一种数据类型来说，底层的支持可能是多种数据结构，什么时候使用哪种数据结构，这就涉及到了编码转换问题

那我们就来看看，不同的数据类型是如何进行编码转化的：

*  String：存储数字的话，采用 int 类型的编码，如果是非数字的话，采用 raw 编码；
 *  List：List 对象的编码可以是 ziplist 或 linkedlist，字符串长度 < 64 字节且元素个数 < 512 使用 ziplist 编码，否则转化为 linkedlist 编码；  
    注意：这两个条件是可以修改的，在 redis.conf 中：

list-max-ziplist-entries 512
    list-max-ziplist-value 64

*  Hash：Hash 对象的编码可以是 ziplist 或 hashtable。
    
     *  当 Hash 对象同时满足以下两个条件时，Hash 对象采用 ziplist 编码：
        
         *  Hash 对象保存的所有键值对的键和值的字符串长度均小于 64 字节
         *  Hash 对象保存的键值对数量小于 512 个。
     *  否则就是 hashtable 编码。
 *  Set：
    
     *  Set 对象的编码可以是 intset 或 hashtable，intset 编码的对象使用整数集合作为底层实现，把所有元素都保存在一个整数集合里面。
     *  保存元素为整数且元素个数小于一定范围使用 intset 编码，任意条件不满足，则使用 hashtable 编码；
 *  Zset：
    
     *  Zset 对象的编码可以是 ziplist 或 zkiplist，当采用 ziplist 编码存储时，每个集合元素使用两个紧挨在一起的压缩列表来存储。
     *  Ziplist 压缩列表第一个节点存储元素的成员，第二个节点存储元素的分值，并且按分值大小从小到大有序排列。
     *  当 Zset 对象同时满足一下两个条件时，采用 ziplist 编码：
        
         *  Zset 保存的元素个数小于 128。
         *  Zset 元素的成员长度都小于 64 字节。
     *  如果不满足以上条件的任意一个，ziplist 就会转化为 zkiplist 编码

## redis为什么使用单线程 ##

我们需要明确的是：**Redis的单线程指的是Redis的网络IO以及键值对指令读写是由一个线程来执行的。对于redis的持久化，集群数据同步、异步删除等都是其他线程执行。**

至于为啥用单线程，我们先了解多线程有什么缺点。

### 多线程的弊端 ###

使用多线程，通常可以增加系统吞吐量，充分利用CPU资源

但是，使用多线程后，没有良好的系统设计，可能会出现如下图所示的场景，增加了线程数量，前期吞吐量会增加，再进一步新增线程的时候，系统吞吐量几乎不再新增，甚至会下降！  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_13_color_FFFFFF_t_70_g_se_x_16]

*  在运行每个任务之前，CPU 需要知道任务在何处加载并开始运行。也就是说，系统需要帮助它预先设置 CPU 寄存器和程序计数器，这称为 CPU 上下文。
 *  这些保存的上下文存储在系统内核中，并在重新计划任务时再次加载。这样，任务的原始状态将不会受到影响，并且该任务将看起来正在连续运行。
 *  **切换上下文时，我们需要完成一系列工作，这是非常消耗资源的操作**。
 *  另外，当多线程并行修改共享数据的时候，为了保证数据正确，需要**加锁机制就会带来额外的性能开销**，面临的共享资源的并发访问控制问题。
 *  引入多线程开发，就需要使用同步原语来保护共享资源的并发读写，**增加代码复杂度和调试难度**

### 单线程的好处 ###

*  不会因为线程创建导致的性能消耗；
 *  避免上下文切换引起的 CPU 消耗，没有多线程切换的开销；
 *  避免了线程之间的竞争问题，比如添加锁、释放锁、死锁等，不需要考虑各种锁问题。
 *  代码更清晰，处理逻辑简单。

### 单线程是否没有充分利用 CPU 资源呢？ ###

官方答案：因为 Redis 是基于内存的操作，CPU 不是 Redis 的瓶颈，Redis 的瓶颈最有可能是机器内存的大小或者网络带宽。既然单线程容易实现，而且 CPU 不会成为瓶颈，那就顺理成章地采用单线程的方案了

## IO多路复用 ##

Redis采用IO多路复用技术，并发处理连接。采用了epoll+自己实现的简单的事件框架。epoll中的读、写、关闭、连接都转换成了事件，然后利用了epoll的复用特性，绝不在 IO 上浪费一点时间。

### 为什么redis要使用IO多路复用 ###

*  因为reddis是跑在单线程中的，所有的操作都是按照顺序线性执行的
 *  但是由于读写操作等待用户输入输出都是阻塞的，所以IO操作在一般情况下往往不能直接返回，这会导致某一文件的IO操作导致整个进程无法对其他客户提供服务
 *  而IO多路复用就是为了解决这个问题而出现的。

### 阻塞IO与非阻塞IO ###

当我们调度套接字的读写方法，默认它们是阻塞的

*  比如read方法要传递进入一个参数n，表示最多读取n个字节后再返回，如果一个字节都没有，线程就会卡在那里，直到新的数据到来获取连接关闭，read方法才可以返回，线程才能继续处理
 *  write方法一般来说不会阻塞，除非内核为套接字分配的写缓存已经满了，write方法就会阻塞，直到缓冲区有空间空闲出来

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_20_color_FFFFFF_t_70_g_se_x_16 5]  
而对于一个基本的网络 IO 模型，当处理 get 请求，会经历以下过程：

*  和客户端建立建立 accept;
 *  从 socket 种读取请求 recv;
 *  解析客户端发送的请求 parse;执行 get 指令；
 *  响应客户端数据，也就是 向 socket 写回数据。

其中，bind/listen、accept、recv、parse 和 send 属于网络 IO 处理，而get属于键值数据操作。既然redis是单线程，那么，最基本的一个实现是在一个线程中依次执行上面说的操作  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_15_color_FFFFFF_t_70_g_se_x_16]

关键点就是**accept 和 recv 会出现阻塞**

*  当 Redis 监听到一个客户端有连接请求，但一直未能成功建立起连接时，会阻塞在 accept() 函数这里，导致其他客户端无法和 Redis 建立连接。
 *  类似的，当 Redis 通过 recv() 从一个客户端读取数据时，如果数据一直没有到达，Redis 也会一直阻塞在 recv()。

>  *  **Blocking I/O**：当使用read或者write对某一个文件描述符FD进行读写时，如果当前FD不可读或者不可写时，整个redis服务就不会对其他的操作做出响应，导致整个服务不可用。因此redis的网络套接字必须设置为非阻塞的
>  *  阻塞模型虽然在开发中非常常见也非常容易理解，但是**由于它会影响其他FD对应服务，所以在需要处理多个客户端任务的时候，往往都不会使用阻塞模型**

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_20_color_FFFFFF_t_70_g_se_x_16 6]

非阻塞IO在套接字对象上提供了一个选项non\_blocking：

*  当这个选项打开时，读写方法不会阻塞，而是能读多少就读多少，能写多少就写多少
 *  能读多少取决于内核为套接字分配的读缓存区内部的数据字节数，能写多少取决于内核为套接字分配的写缓冲区的空闲空间字节数
 *  读方法和写方法会通过返回值告知程序实际读写了多少字节

有了非注销IO就意味着线程在读写IO时就可以不必阻塞了，读写可以瞬间完成，然后线程就可以继续干别的事情了。

### 什么是IO多路复用 ###

所谓**IO多路复用**：

*  **多路**指的是多个socket连接
 *  **复用**指的是复用一个线程。

非阻塞IO有个问题，那就是线程要读数据，结果读了一部分就返回了，那么线程如何知道何时才应该继续读----也就是说，当数据到来时，线程如何得到通知。写也是一样，如果缓冲区满了，写不完，剩下的数据何时才应该继续写，线程也应该得到通知。

多路复用（事件轮询API）就是用来解决这个问题的。最简单的事件轮询API是select函数，它是操作系统提供给用户程序的API。输入是读写描述符的read\_fds和write\_fds，输出是与之对应的可读可写事件；同时还提供了一个timeout参数，如果没有任何事件到来，那么就最多等待timeout的值得时间，线程处于阻塞状态。一旦期间有任何事件到来，就可以立即返回。时间过了之后还是没有任何事件到来，也会立即返回。如下，拿到事件之后，线程就可以继续挨个处理相应的事件。处理完了继续过来轮询。于是线程就进入了一个死循环，我们把这个死循环称为事件循环，一个循环为一个周期  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_19_color_FFFFFF_t_70_g_se_x_16]

![在这里插入图片描述][da62f6ab31c747dd82cc148b1fd198c2.png]  
因为我们通过select系统调用同时处理多个通道描述符的读写事件，因此我们将这类系统调用称为多路复用API。多路复用主要有三种技术：select，poll，epoll。现代操作系统的多路复用API已经不再使用select系统调用，而改用epoll，因为select系统调用的性能在描述符多的时候会变得非常差

它的基本原理是：**内核不是监视应用程序本身的连接，而是监视应用程序的文件描述符**

*  当客户端运行时，它将生成具有不同事件类型的套接字。
 *  在服务器端，I / O 多路复用模块会将消息放入队列（也就是 下图的 I/O 多路复用程序的 socket 队列），然后通过文件事件分派器将其转发到不同的事件处理器

> redis单线程情况下，内核会一直监听socket上的连接请求或者数据请求，一旦有请求到达就交给redis线程处理，这就实现了一个redis线程处理多个IO流的效果

*  redis会将每个客户端套接字都管理一个指令队列。客户端的指令通过队列来排队进行顺序处理，先到先服务
 *  redis同样会为每个客户端套接字关联一个响应队列。redis服务器通过响应队列来将指令的返回结果回复给客户端。如果队列为空，那么意味着连接暂时出于空闲状态，不需要去获取写事件，也就是可以将当前客户端描述符从write\_fds里面移出来。等待队列里有数据了，再将描述符放进去，避免select系统调用立即返回写事件，结果发现没有什么数据可以写，出现这种情况的线程会令CPU消耗大增

### 阻塞IO VS IO多路复用 ###

假设某一时刻与redis服务器建立了一万个长连接。

对于阻塞式 IO 的做法就是

*  对每一条连接都建立一个线程来处理，那么就需要 1万个线程， 同时根据我们的经验
    
     *  对于 IO 密集型的操作我们一般设置，线程数 = 2 \* CPU 数量 + 1
     *  对于 CPU 密集型的操作一般设置线程 = CPU 数量 + 1。
 *  当然各种书籍或者网上也有一个详细的计算公式可以算出更加合适准确的线程数量
 *  但是得到的结果往往是一个比较小的值
 *  像阻塞式IO这样创建成千上万的线程，系统是无法承载这样的负荷更谈不上高效的吞吐量和服务了。

而多路复用的做法是：

*  用一个线程将这一万个建立成功的连接陆续放入event\_poll、event\_poll会为这一万个长连接注册回调函数
 *  当某一个长连接准备就绪后（建立连接成功，数据读取完成等），就会通过回调函数写入到 event\_poll 的就绪队列 rdlist 中
 *  这样这个单线程就可以通过读取 rdlist 获取到需要的数据。

**通过这种方式，就可以用 1 个或者几个线程来处理大量的连接了，极大的提升了吐吞量**

需要注意的是，

*  除了异步IO外，其他IO模型其实都可以归类为阻塞式IO模型
 *  不同的是像阻塞式IO模型在第一阶段读取数据的时候，如果此时数据未准备就绪需要阻塞，在第二阶段数据准备就绪后需要将数据从内核复制到用户态这一步也是阻塞的。
 *  而多路复用 IO 模型在第一阶段是不阻塞的，只会在第二阶段阻塞。

### 事件处理机制 ###

Redis客户端与Redis服务端建立连接，发送命令，Redis服务器响应命令都是需要通过事件机制来做的

*  select/epoll提供了基于事件的回调机制，即针对不同事件的发生，调用相应的事件处理器。所以redis一直在处理事件，提升redis的响应性能。
 *  redis线程不会阻塞在某一个特定的监听或者已连接套接字上。也就是说，不会阻塞在某一个特定的客户端请求连接上。因此，redis可以同时和多个客户端连接并处理并发请求，从而提升并发性

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_18_color_FFFFFF_t_70_g_se_x_16 6]

大体上可以说Redis的工作模式是

*  reactor 模式配合一个队列，用一个 serverAccept 线程来处理建立请求的链接，并且通过 IO 多路复用模型，让内核来监听这些 socket
 *  一旦某些 socket 的读写事件准备就绪后就对应的事件压入队列中，然后 worker 工作，由文件事件分派器从中获取事件交于对应的处理器去执行
 *  当某个事件执行完成后文件事件分派器才会从队列中获取下一个事件进行处理

### Reactor设计模式 ###

Redis服务采用Reactor的方式来实现文件事件处理器（每一个网络连接都对应一个文件描述符）

*  文件事件处理器使用IO多路复用模块同时监听多个FD
 *  当accept、read、write和close等事件产生时，文件事件处理器就会回调FD绑定的事件处理器  
    ![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_20_color_FFFFFF_t_70_g_se_x_16 7]

虽然整个文件事件处理器是在单线程上运行的，但是通过IO多路复用模块的引入，实现了同时对多个FD读写的监控，提高了网络通信模型的性能，同时也可以保证了整个Redis服务实现的简单

### IO多路复用模块 ###

IO多路复用模块封装了底层的select、epoll、avport以及kqueue这些IO多路复用函数，为上层提供了相同的接口  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_20_color_FFFFFF_t_70_g_se_x_16 8]  
因为Redis需要在多个平台上运行，同时为了最大化执行的效率和性能，所以会根据编译平台的不同选择不同的IO多路复用函数作为子模块。具体选择过程如下。  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_20_color_FFFFFF_t_70_g_se_x_16 9]

*  redis会优先选择时间复杂度为O(1)的IO多路复用函数作为底层实现，包括solaries 10 中的 evport、Linux 中的 epoll 和 macOS/FreeBSD 中的 kqueue
 *  上述的这些函数都使用了内核内部的结构，并且能够服务几十万的文件描述符。

### 定时任务 ###

服务器除了要响应IO事件外，还要处理其他事情，比如定时任务就是非常重要的一件事。如果线程阻塞在epoll系统调用上，定时任务将无法得到准时调度。那么redis是如何解决这个问题的呢？

*  redis的定时任务会记录在一个被称为“最小堆”的数据结构中。在这个堆中，最快要执行的任务排在堆对的最上方
 *  在每个循环周期里，redis都会对最小堆里面已经到时间点的任务进行处理
 *  处理挖鼻之后，将最快要执行的任务还需要的时间记录下来，这个时间就是select系统调用的tiemout参数
 *  因为redis知道未来timeout的值的时间内，没有任务要处理，所以可以安心睡眠timeout的值的时间

# 参考 #

*  [https://www.cnblogs.com/samdyli/p/12489305.html][https_www.cnblogs.com_samdyli_p_12489305.html]
 *  [https://draveness.me/redis-io-multiplexing/][https_draveness.me_redis-io-multiplexing]
 *  [https://baijiahao.baidu.com/s?id=1681232596353681258&wfr=spider&for=pc][https_baijiahao.baidu.com_s_id_1681232596353681258_wfr_spider_for_pc]
 *  [https://www.cnblogs.com/xlecho/archive/2019/11/10/11832118.html][https_www.cnblogs.com_xlecho_archive_2019_11_10_11832118.html]
 *  [https://segmentfault.com/a/1190000017375843][https_segmentfault.com_a_1190000017375843]

[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_10_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/0bec9a54c7514563a9424f2d506cef98.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_20_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/df3c224ddea44953ac907188073fbe91.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_20_color_FFFFFF_t_70_g_se_x_16 1]: /images/20220828/3e6fe31253ac4e4aaa61ce5f54f93284.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_18_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/3586c35b4925408f8434babdd75d9742.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_16_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/004c2f5e6aec4345a1234b3e66bc242d.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_18_color_FFFFFF_t_70_g_se_x_16 1]: /images/20220828/140e64cc6391430dbabd936be3c1d17a.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_18_color_FFFFFF_t_70_g_se_x_16 2]: /images/20220828/1a8e5b3e8fcc41d6a60df34d0da00469.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_18_color_FFFFFF_t_70_g_se_x_16 3]: /images/20220828/dd968af6aa0742c786fe6d5917566895.png
[1d0eb34075b94fff8165fc692bf65f27.png]: /images/20220828/cb94b7b77d424cb1982cf6561f672afc.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_18_color_FFFFFF_t_70_g_se_x_16 4]: /images/20220828/7a3edff02e3a4f15a7494b85f5e576ca.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_20_color_FFFFFF_t_70_g_se_x_16 2]: /images/20220828/002fca63b98749e6af0ea1e2123268f8.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_20_color_FFFFFF_t_70_g_se_x_16 3]: /images/20220828/331ec64f57f64ec68ced8351db5dbc40.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_20_color_FFFFFF_t_70_g_se_x_16 4]: /images/20220828/26631285d2854f16ba3e650ae890637a.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_18_color_FFFFFF_t_70_g_se_x_16 5]: /images/20220828/ac81a27055c3412bb91ac1b77322e99a.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_13_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/ecd6cb08c28844fba81eec48cac45c6b.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_20_color_FFFFFF_t_70_g_se_x_16 5]: /images/20220828/6d2d2f2d1f984e26ae24f8f905f82811.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_15_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/a65bcac65337475fa83a4c1290738e95.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_20_color_FFFFFF_t_70_g_se_x_16 6]: /images/20220828/cff87906bacb43e0b869d6d17059dfe1.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_19_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/40c00b16f84344ff9fef8789f4d9f2ed.png
[da62f6ab31c747dd82cc148b1fd198c2.png]: /images/20220828/d95762dba50b45b49a2d01ddbbf79f00.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_18_color_FFFFFF_t_70_g_se_x_16 6]: /images/20220828/86ef7288a5674fbeae137a1b3c5760f8.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_20_color_FFFFFF_t_70_g_se_x_16 7]: /images/20220828/f7b55313372c4d9d84bc8a1255d7c065.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_20_color_FFFFFF_t_70_g_se_x_16 8]: /images/20220828/c5d1fb1aa0724e57b6e6c387e4be5bd6.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_20_color_FFFFFF_t_70_g_se_x_16 9]: /images/20220828/4ba15ce0a6d4484695703a7df7c5859f.png
[https_www.cnblogs.com_samdyli_p_12489305.html]: https://www.cnblogs.com/samdyli/p/12489305.html
[https_draveness.me_redis-io-multiplexing]: https://draveness.me/redis-io-multiplexing/
[https_baijiahao.baidu.com_s_id_1681232596353681258_wfr_spider_for_pc]: https://baijiahao.baidu.com/s?id=1681232596353681258&wfr=spider&for=pc
[https_www.cnblogs.com_xlecho_archive_2019_11_10_11832118.html]: https://www.cnblogs.com/xlecho/archive/2019/11/10/11832118.html
[https_segmentfault.com_a_1190000017375843]: https://segmentfault.com/a/1190000017375843