2026.3.13 Redis的网络模型

用户空间和内核空间

任何Linux发行版，其系统内核都是Linux。我们的应用都需要通过Linux内核和硬件交互。

为了避免用户应用导致冲突甚至内核崩溃，用户应用与内核应是分离的：

进程的寻址空间会划分为两部分：内核空间 、用户空间。
用户空间只能执行受限的命令（Ring3），而且不能直接调用系统资源，必须通过内核提供的接口访问。
内核空间可以执行特权指令（Ring0），调用一切系统资源。

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

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

以读数据为例：

在《UNIX网络编程中》，总结归纳了五种IO模型：

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

阻塞IO

顾名思义，阻塞IO就是两个阶段（等待数据就绪，读取数据）都必须阻塞等待。用户应用必须等待内核缓冲区的数据就绪，就绪之后还必须等待内核缓冲区的数据完全拷贝到用户缓冲区中。因此，该网络模型的性能较差

非阻塞IO

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

再细一点，非阻塞IO在1阶段等待数据时是非阻塞的，而在2阶段拷贝数据时仍然是阻塞的

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

IO多路复用

无论是阻塞IO还是非阻塞IO，它们在第一阶段都需要调用recvfrom获取数据，差别在于无数据时的处理方案：

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

比如服务端处理客户端Socket请求时，在单线程情况下，只能依次处理每一个Socket，如果正在处理的Socket恰好未就绪（数据不可读或不可写），线程就被会阻塞，所有其他客户端的Socket就会被阻塞，性能自然会很差。

提高效率的办法：

多线程
不排队，谁的数据就绪了，用户应用就去拷贝谁的数据

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

IO多路复用：利用单个线程同时监听多个FD，并在某个FD可读、可写时得到通知，从而避免无效等待，充分利用CPU资源。

在监听FD的方式、通知方式又有多种实现，常见的有：

select
poll
epoll

差异：

select和poll会通知用户进程有FD就绪，但不确定是哪个FD，需要用户进程逐个遍历FD来确认。
epoll则会在通知用户进程有FD就绪时，把已就绪的FD写入用户空间。

IO多路复用-select

c 复制代码

// 定义类型别名，__fd_mask，本质是long int
typedef long int __fd_mask;

//fd_set 记录要监听的fd集合，以及其对应的状态
typedef struct{
    //fds_bits是long类型的数组，长度为1024/32 = 32
    //共1024个bit位，每个bit位代表一个fd，0代表未就绪，1代表就绪
    __fd_mask fds_bits[__FD_SETSIZE / __NFDBITS];
    //...
} fd_set;

//select 函数，用于监听多个fd集合
int select(
	int nfds, // 要监听的fd_set最大的fd+1
    fd_set *readfds, // 要监听读事件的fd集合
    fd_set *writefds, // 要监听写事件的fd集合
    fd_set *exceptfds // 要监听异常事件的fd集合
    //超时时间，null-永不超时；0-不阻塞等待；大于0-固定等待时间
    struct timeval *timeout
);

select模式存在的问题：

需要将整个fd_set从用户空间拷贝到内核空间，select结束还要拷贝回用户空间
select无法得知具体哪个fd就绪，需要遍历fd_set数组
fd_set监听的fd数量不能超过1024

IO多路复用-poll

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

c 复制代码

// pollfd中的事件类型
#define POLLIN //可读事件
#define POLLOUT //可写事件
#define POLLERR //错误事件
#define POLLNVAL //fd未打开

//pollfd结构
struct pollfd{
    int fd; //要监听的fd
    short int events; //要监听的事件类型：读、写、异常
    short int revents; //实际发生的事件类型
}

// poll函数
int poll(
    struct pollfd *fds, //pollfd数组，可以自定义大小
    nfds_t nfds, //数组元素个数
    int timeout //超时时间
);

IO流程：

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

与select对比：

select模式中fd_set大小固定为1024，而pollfd在内核中采用链表，理论上无上限
监听fd越多，每轮遍历消耗时间越久，性能越差

IO多路复用-epoll

epoll模式是对select和poll的改进，它提供了3个函数

c 复制代码

struct eventpoll{
    //...
    struct rb_root rbr; // 一棵红黑树，记录要监听的fd
    struct list_head rdlist; // 一个链表，记录就绪的fd
    //...
}

// 1.会在内核创建eventpoll结构体，返回对应的句柄epfd
int epoll_creat(int size);

// 2.将一个fd添加到epoll的红黑树中，并设置ep_poll_callback
//callback触发时，就把对应的FD加入到rdlist这个就序列表中
int epoll_ctl{
    int epfd, // epoll实例的句柄
    int op, // 要执行的操作，包括：ADD、MOD、DEL
    int fd, //要监听的FD
    struct epoll_event *event
};

// 3.检查rdlist列表是否为空，不为空则返回就绪的fd数量
int epoll_wait(
    int epfd, //eventepoll实例句柄
    struct epoll_event *events, //空event数组，用于接收就绪的fd
    int maxevents, //events数组的最大长度
    int timeout //超时时间，-1永不超时；0不阻塞；大于0为阻塞时间
);

epoll模式与前两者的比较：

红黑树保存要监听的fd，理论上无上限；而且增删改查的效率都非常高，性能不会随监听的fd增多而下降
每个fd只需要执行一个epoll_ctl添加到红黑树，以后每次epoll_wait无需传递任何参数，无需重复拷贝fd到内核空间。
内核会将就绪的fd拷贝到用户空间的指定位置，用户进程无需遍历所有的fd就能找到就绪的fd是谁

IO多路复用-事件通知机制

当FD有数据可读时，我们调用epoll_wait就可以得到通知，事件通知的方式有两种：

LevelTriggered：简称LT。当FD有数据可读时，就会重复通知多次，直到数据处理完毕。这也是epoll的默认模式
EdgeTriggered：简称ET。当FD有数据可读时，只会通知一次，不管数据是否处理完毕。

举个例子：

假设一个客户端socket对应的FD已经注册到epoll实例中
客户端向epoll发送了2kb的数据
服务端调用epoll_wait，得到通知说FD已就绪
服务端从FD读取了1kb的数据
回到步骤三（再次调用epoll_wait，形成循环，直至数据处理完毕）

总结：

ET模式避免了LT模式可能出现的惊群现象
ET模式最好结合非阻塞IO读取FD数据，性能相较LT会好一些，但是实现起来会更复杂。

IO多路复用-web服务流程

基于epoll模式的web服务基本流程

信号驱动IO

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

该模式的进程不阻塞与非阻塞IO的不阻塞不一样，非阻塞IO仍然会进行忙等，而信号驱动IO的用户进程可以执行其他的业务。

缺点：

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

异步IO

异步IO的整个过程都是非阻塞的，用户进程调用完异步IO的API后就可以做其他事情，内核等待数据就绪并拷贝到用户空间后才会递交信号，通知用户进程。

异步IO在高并发的情况下，内核积累的IO读写任务会过多，而IO读写效率较低，所以每次新增任务都会导致大量内存的消耗，容易出现内存占用过多崩溃的现象。所以如果要使用异步IO，就必须做好并发访问的限流，这样做的话代码复杂度会很高，综合比起来还是不如IO多路复用。

只有异步IO没有任何阻塞，两个阶段都不阻塞

Redis网络模型

Redis到底是单线程还是多线程？

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

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

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

为什么Redis要选择单线程？

抛开持久化不谈，Redis是纯内存操作，执行速度非常快，它的性能瓶颈是网络延迟而不是执行速度，因此多线程并不能带来巨大的性能提升
多线程会带来过多的上下文切换，带来不必要的开销
多线程必然会面临线程安全的问题，那么就必然需要引入线程锁机制，实现复杂度增高的同时，性能也会大打折扣。