IO顾名思义就是进行输入与输出，对于Redis来说可描述为Redis服务进程想要从内核中的读取Redis客户端发送的请求，然后进行数据的内核空间到用户空间的拷贝的过程，反之客户端获取数据也一样，在目前的网络编程中，一般常见的IO模型有5种，分别是：
阻塞IO:用户进程检查一下内核是否有数据，没有则等待数据，整个等待过程中是用户进程是阻塞的，直到有数据为止。拷贝过程也是阻塞的。
非阻塞IO：用户进程检查一下内核是否有数据，没有则立刻返回获取失败的信息，然后不断重复尝试，直到有数据为止。拷贝过程依然是阻塞的。
IO多路复用：
利用单个线程来同时监听多个FD(文件描述符，可理解为Socket），并在某个FD可读、可写的时候得到通知，从而避免无效的等待。其中监听FD的方式、通知的方式也有多种实现，常见的有：
1.select：是最早Linux中使用的多路复用的实现方案，具体实现是，selector会维护3个FD集合：需要监听读事件的FD集合、需要监听写事件的FD集合、需要监听异常事件的FD集合。首先用户空间需要创建一个所有需要监听读的FD集合传入selector，selector在内核空间内会去检查是否有就绪的FD，如果没有就休眠，有就返回FD就绪信息给用户空间，用户空间需要遍历FD就绪信息来确定数据属于哪一个FD。FD集合使用了BitMap的数据结构，其大小是有限的。
2.poll：对select模式做了简单的改进，其改进点是：用户进程创建一个FD数组，将数组拷贝到内核空间，并且转换为链表储存，其大小是没有上限的。
3.epoll：为Redis的使用的IO模型的具体实现，epoll模式是对select和poll的改进，它提供了三个函数，其具体作用为：
（1）在内核中创建eventpoll的结构体，其中包含了一个红黑树，记录需要监听的FD，以及一个链表，记录就绪的FD。
（2）对一个FD进行eventpoll的红黑数中相应的添加、删除、修改的操作。
（3）检查eventpoll中就绪FD链表是否为空，如果不为空就返回已就绪FD的数量，同时将eventpoll中就绪FD链表拷贝到用户空间。
具体流程为：
信号驱动IO：与内核建立SIGIO的信号关联并设置回调，当内核有FD就绪时，会发出SIGIO信号通知用户，期间用户进程无需阻塞等待。
异步IO：整个过程都是非阻塞的，用户进程调用异步API后就可以去做其他事情，内核等待数据就绪并拷贝到用户空间后才会递交信号，通知用户进程。不过性能不如IO多路复用。
