Redis 的IO

用户空间和内核空间

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

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

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

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

阻塞 IO

顾名思义，阻塞 IO 就是两个阶段都必须阻塞等待:

非阻塞IO

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

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

IO多路复用

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

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

比如服务端处理客户端Socket请求时，在单线程情况下，只能依次处理每一个socket，如果正在处理的socket恰好末就绪(数据不可读或不可写)，线程就会被阻塞，所有其它客户端socket都必须等待，性能自然会很差。

提高效率的几种办法？

方案一 : 增加更多服务员(多线程)

方案二: 不排队，谁想好了吃什么(数据就绪了)，服务员就给谁点餐(用户应用就去读取数据)

那么问题来了: 用户进程如何知道内核中数据是否就绪呢?

文件描述符(File Descriptor):简称FD，是一个从0开始递增的无符号整数，用来关联Linux中的一个文件。在Linux中，一切皆文件，例如常规文件、视频、硬件设备等，当然也包括网络套接字(Socket) IO多路复用:是利用单个线程来同时监听多个FD，并在某个FD可读、可写时得到通知，从而避免无效的等待，充分利用CPU资源。

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

不过监听FD的方式、通知的方式又有多种实现，常见的有: select 、poll、epoll

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

IO多路复用------select

select是Linux中最早的IO多路复用实现方案

select模式存在的问题:

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

IO多路复用------poll

poll模式对select模式做了简单改进，但性能提升不明显，部分关键代码如下:

IO 流程:

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

与select对比:

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

IO多路复用------epoll

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

IO多路复用------时间通知机制

当FD有数据可读时，我们调用epoll_wait就可以得到通知。但是事件通知的模式有两种:

• LevelTriggered:简称LT。当FD有数据可读时，会重复通知多次，直至数据处理完成。是Epoll的默认模式。
• EdgeTriggered:简称ET。当FD有数据可读时，只会被通知一次，不管数据是否处理完成。

1. 假设一个客户端socket对应的FD已经注册到了epoll实例中
2. 客户端socket发送了2kb的数据
3. 服务端调用epoll_wait，得到通知说FD就绪
4. 服务端从FD读取了1kb数据
5. 回到步骤3(再次调用epoll_wait，形成循环)

IO多路复用------Web服务流程

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

信号驱动IO

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

异步IO

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

可以看到，异步IO型中，用户进程在两个阶段都是非阻塞状态。

IO操作是同步还是异步，关键看数据在内核空间与用户空间的拷贝过程(数据读写的IO操作)，也就是阶段二是同步还是异步: