Redis使用IO多路复用进行事件处理机制

一、epoll多路复用

这里重点要说的就是redis的IO编程模型，首先了解下

为什么要有多路复用呢 ？

案例

引用知乎上一个高赞的回答来解释什么是I/O多路复用。假设你是一个老师，让30个学生解答一道题目，然后检查学生做的是否正确，你有下面几个选择：

第一种选择：按顺序逐个检查，先检查A，然后是B，之后是C、D....这中间如果有一个学生卡住，全班都会被耽误。这种模式就好比，你用循环挨个处理socket，根本不具有并发能力。

第二种选择：你创建30个分身，每个分身检查一个学生的答案是否正确。 这种类似于为每一个用户创建一个进程或者 - 线程处理连接。

第三种选择，你站在讲台上等，谁解答完谁举手。这时C、D举手，表示他们解答问题完毕，你下去依次检查C、D的答案，然后继续回到讲台上等。此时E、A又举手，然后去处理 E 和 A。

如果没有多路复用，一个线程只能监听一个端口的一个连接，这样这个效率比较低。当然我们有几种办法可以破除这个，一个是使用多线程模型，我们还是监听一个端口，

但是一个请求进来，我们为其创建一个线程。但是这种消耗是比较大的。所以我们一直想办法，有没有办法一个线程监听多个端口，或者多个一个端口的多个连接（fd）。

这里再说说fd， 文件描述符（file descriptor）是内核为了高效管理已被打开的文件所创建的索引，其是一个非负整数（通常是小整数），用于指代被打开的文件，

所有执行I/O操作(包括网络socket操作)的系统调用都通过文件描述符。每个连接请求上来，都会创建一个连接套接字，一个连接使用一个连接套接字。

对于监听端口，我们会有一个监听套接字，对应监听fd。我们所有的监听业务都是从监听这个套接字开始的。

那么如果我一个程序能同时监听多个连接套接字，是不是就很赞了。是的，这就是linux的io多路复用逻辑。但是这么多连接套接字，传递数据等是断断续续的，

A连接接收一个包，B连接再接收一个包，A连接再接收一个包，B连接再接收一个包....如果我等着A连接把包都接收完再处理B，那效率是非常慢的。所以，

这里我们就需要有一个通知机制，让有收到包的时候通知下处理线程。

linux的IO多路复用逻辑主要有三种：select、 poll、 epoll

select

select模型监听的三个事件：读数据事件，写数据事件，异常事件。

使用select模型的步骤如下：

• 我们确定要监听的监听fd列表

• 调用select监听所有监听fd，阻塞线程。

• select只有当有事件出现并且有事件的fd已经等待完毕

• 如果是创建一个连接事件：

  • 创建一个连接套接字，连接fd

  • 将连接fd和监听fd集合放在一起

如果是一个读写事件：

• 遍历所有fd，判断是否是准备好的fd

• 如果是准备好的fd，进行业务读写逻辑

poll模型：

poll传递给内核的是：

• 监听的fd集合

• 需要监听的事件类型

• 实际发生的事件类型

poll的模型逻辑是：

• 我们确定要监听的监听fd列表

• 调用poll监听所有监听fd，阻塞线程。

• poll只有当有事件出现才解除阻塞

• 如果是创建一个连接事件：

  • 创建一个连接套接字，连接fd

  • 将连接fd和监听fd集合放在一起

如果是一个读写事件：

• 遍历所有fd，判断是否是有读写事件的fd

• 如果fd有读写事件，进行业务读写逻辑