Unix IO模型分类
- Blocking IO - 阻塞IO
- NoneBlocking IO - 非阻塞IO
- IO multiplexing - IO多路复用
- signal driven IO - 信号驱动IO
- asynchronous IO - 异步IO
阻塞IO - Blocking IO
最传统的一种IO模型，即在读写数据过程中会发生阻塞现象。
当用户线程发出IO请求之后，内核会去查看数据是否就绪，如果没有就绪就会等待数据就绪，而用户线程就会处于阻塞状态，用户线程交出CPU。当数据就绪之后，内核会将数据拷贝到用户线程，并返回结果给用户线程，用户线程才解除block状态。
也许有人会说，可以采用多线程+ 阻塞IO 来解决效率问题，但是由于在多线程 + 阻塞IO 中，每个socket对应一个线程，这样会造成很大的资源占用，并且尤其是对于长连接来说，线程的资源一直不会释放，如果后面陆续有很多连接的话，就会造成性能上的瓶颈。
非阻塞IO - NoneBlocking IO
当用户线程发起一个 IO 操作后，并不需要等待，而是马上就得到一个结果。如果结果是一个 error 时，它就知道数据还没有准备好，于是它可以再次发送 IO 操作。一旦内核中的数据准备好了，并且又再次收到了用户线程的请求，那么它马上就将数据拷贝到了用户线程，然后返回。
在非阻塞IO 模型中，用户线程需要不断地询问内核数据是否就绪，也就说非阻塞IO不会交出CPU，而会一直占用CPU。
与阻塞IO的区别：
- 无数据时是否会直接返回
- 是否会交出CPU
对于非阻塞IO就有一个非常严重的问题，在while循环中需要不断地去询问内核数据是否就绪，这样会导致CPU占用率非常高，因此一般情况下很少使用while循环这种方式来读取数据。
非阻塞IO核心流程：
-
非阻塞式主要体现在用户进程发起recvfrom系统调用的时候,这个时候系统内核还没有接收到数据报,直接返回错误给用户进程,告诉“当前还没有数据报可达,晚点再来”
-
用户进程接收到信息,但是用户进程不知道什么时候数据报可达,于是就开始不断轮询(polling)向系统内核发起recvfrom的系统调用“询问数据来了没”,如果没有则继续返回错误
-
用户进程轮询发起recvfrom系统调用直至数据报可达,这个时候需要等待系统内核复制数据报到用户进程的缓冲区,复制完成之后将返回成功提示
IO多路复用 - IO multiplexing
IO 多路复用是一种同步IO模型，实现一个线程可以监视多个文件句柄；一旦某个文件句柄就绪，就能够通知应用程序进行相应的读写操作；没有文件句柄就绪就会阻塞应用程序，交出CPU。多路是指网络连接，复用指的是同一个线程。
不管是同步阻塞还是同步非阻塞，对系统性能的提升都是很小的。而通过复用可以使一个或一组线程（线程池）处理多个TCP连接。IO多路复用使用两个系统调用（select/poll/epoll和recvfrom），blocking IO只调用了recvfrom。select/poll/epoll核心是可以同时处理多个connection，而不是更快，所以连接数不高的话，性能不一定比多线程+阻塞IO好。
由于非阻塞IO的弊端的存在，所以出现了IO多路复用。在多路复用IO模型中，会有一个内核线程不断地去轮询多个 socket 的状态，只有当真正读写事件发送时，才真正调用实际的IO读写操作。因为在多路复用IO模型中，只需要使用一个线程就可以管理多个socket，系统不需要建立新的进程或者线程，也不必维护这些线程和进程，并且只有真正有读写事件进行时，才会使用IO资源，所以它大大减少了CPU资源占用。
信号驱动IO - signal driven IO
在信号驱动IO模型中，当用户线程发起一个IO请求操作，会给对应的socket注册一个信号函数，然后用户线程会继续执行，当内核数据就绪时会发送一个信号给用户线程，用户线程接收到信号后，便在信号函数中调用IO读写操作来进行实际的IO请求操作。这个一般用于UDP中，对TCP套接字几乎没用，原因是该信号产生得过于频繁，并且该信号的出现并没有告诉我们发生了什么请求。
用户进程可以使用信号方式，当系统内核描述符就绪时将会发送SIGNO给到用户空间，这个时候再发起recvfrom的系统调用等待返回成功提示，流程如下：
- 先开启套接字的信号IO启动功能，并通过一个内置安装信号处理函数的signaction系统调用，当发起调用之后会直接返回；
- 其次，等待内核从网络中接收数据报之后，向用户空间发送当前数据可达的信号给信号处理函数；
- 信号处理函数接收到信息就发起recvfrom系统调用等待内核数据复制数据报到用户空间的缓冲区；
- 接收到复制完成的返回成功提示之后，应用进程就可以开始从网络中读取数据。
异步IO - asynchronous IO
前面四种IO模型实际上都属于同步IO，只有最后一种是真正的异步IO，因为无论是多路复用IO还是信号驱动模型，IO操作的第2个阶段都会引起用户线程阻塞，也就是内核进行数据拷贝的过程都会让用户线程阻塞。
- 由POSIX规范定义，告知系统内核启动某个操作，并让内核在整个操作包含数据等待以及数据复制过程的完成之后通知用户进程数据已经准备完成，可以进行读取数据；
- 与上述的信号IO模型区分在于异步是通知我们何时IO操作完成,而信号IO是通知我们何时可以启动一个IO操作
同步与异步的定义
- 同步:发起一个fn的调用,需要等待调用结果返回,该调用结果要么是期望的结果要么是异常抛出的结果,可以说是原子性操作(要么成功要么失败返回)
- 异步: 发起一个fn调用,无需等待结果就直接返回,只有当被调用者执行处理程序之后通过“唤醒”手段通知调用方获取结果(唤醒的方式有回调,事件通知等)
- 小结: 同步和异步关注的是程序之间的通信
阻塞与非阻塞的定义
- 阻塞: 无数据时会阻塞等待有数据才返回
- 非阻塞: 无数据时直接返回无数据，无需等待
- 小结: 阻塞与非阻塞更关注是程序等待结果的状态
- 由此可知,同步、异步与阻塞、非阻塞之间不存在关联,关注的目标是不一样的
IO多路复用有哪些实现
- select
- poll
- epoll
IO多路复用的大致实现
select是内核提供的多路分离函数，使用它可以避免同步非阻塞IO中轮询等待问题。
用户首先将需要进行IO操作的socket添加到select中，然后阻塞等待select系统调用返回。当数据到达时，socket被激活，select函数返回，用户线程正式发起read请求，读取数据并继续执行。
这么一看，这种方式和同步阻塞IO并没有太大区别，甚至还多了添加监视socket以及调用select函数的额外操作，效率更差。但是使用select以后，用户可以在一个线程内同时处理多个socket的IO请求，这就是它的最大优势。用户可以注册多个socket，然后不断调用select读取被激活的socket，即可达到同一个线程同时处理多个IO请求的目的。而在同步阻塞模型中，必须通过多线程方式才能达到这个目的。所以IO多路复用设计目的其实不是为了快，而是为了解决线程/进程数量过多对服务器开销造成的压力。
虽然这种方式允许单线程内处理多个IO请求，但是每个IO请求的过程还是阻塞的（在select函数上阻塞），平均时间甚至比同步阻塞IO模型还要长。如果用户线程只注册自己感兴趣的socket，然后去做自己的事情，等到数据到来时在进行处理，则可以提高CPU利用率。
通过Reactor方式，用户线程轮询IO操作状态的工作统一交给handle_events事件循环处理。用户线程注册事件处理器之后可以继续执行做其他的工作（异步），而Reactor线程负责调用内核的select函数检查socket状态。当有socket被激活时，则通知相应的用户线程（或执行用户线程的回调函数），执行handel_envent进行数据的读取、处理工作。
由于select函数是阻塞的，因此多路IO复用模型就被称为异步阻塞IO模型，这里阻塞不是指socket。因为使用IO多路复用时，socket都设置NONBLOCK，不过不影响，因为用户发起IO请求时，数据已经到达了，用户线程一定不会被阻塞。
IO多路复用是最常用的IO模型，但其异步程度还不彻底，因为它使用了会阻塞线程的select系统调用。因此IO多路复用只能称为异步阻塞IO，而非真正的异步IO。
select
select函数监视的文件描述符有三类，readfds，writefds，exceptfds。调用后函数会阻塞，直到有文件描述符就绪（有数据读、写、或者有except），或者超时（timeout指定时间，如果立即返回设置null），函数才会返回。当select函数返回后，可以通过便利fdset，来找到就绪的描述符。
优点：良好的跨平台性。
缺点：单个进程能够监视的文件描述符的数量存在最大限制，在Linux上为1024，可以通过修改宏定义甚至重新编译内核的方式提升这一限制，但这样会造成效率的降低。有文件描述符就绪时需要遍历fd集合获取对应就绪的文件描述符，随着文件描述符的增加遍历的时间也会增加。
poll
与select使用三个位图来表示fdset，poll使用一个pollfd的指针实现。pollfd结构包含了要监视的event和发生的event，不在使用select参数传值的方式。同时pollfd并没有最大数量的限制（但数量过大性能也会下降）。和select一样，poll返回后，需要轮询pollfd来或许就绪的描述符。
优点：无需再传递文件描述符集合；文件描述符的最大数量不再受到限制。
缺点：依然需要遍历文件描述符集合；
epoll
epoll是select和poll的增强版本，相比于前两者，它更加的灵活，没有描述符的限制。epoll使用一个事件表管理多个描述符，将用户关系的文件描述符的事件存放到内核的一个事件表中，这样在用户空间和内核空间的copy只需要一次。
当用户请求时将请求注册到事件表中，然后用户就可以处理其他事情了，内核有专门的线程处理事件列表中的事件，当有文件事件准备就绪时就根据注册的事件信息通知对应的应用程序进行对应的操作事件。这样就解决了select、poll中刚开始sock请求的阻塞问题，但是在数据获取的请求中依然是阻塞的。
redis的线程模型
为什么 Redis 中要使用 I/O 多路复用
为什么 Redis 中要使用 I/O 多路复用这种技术呢？因为 Redis 是跑在单线程中的，所有的操作都是按照顺序线性执行的，但是由于读写操作等待用户输入 或 输出都是阻塞的，所以 I/O 操作在一般情况下往往不能直接返回，这会出现当某一文件的 I/O 阻塞时，导致整个进程无法对其它客户端提供服务。而 I/O 多路复用就是为了解决这个问题而出现的。为了让单线程(进程)的服务端应用同时处理多个客户端的事件，Redis 采用了 IO 多路复用机制。
redis线程模型实现
Redis基于Reactor模式的epoll实现开发了网络事件处理器，这个处理器被称为文件事件处理器。它的组成结构为4部分：多个套接字、IO多路复用程序、文件事件分派器、事件处理器。因为文件事件分派器队列的消费是单线程的，所以Redis才叫单线程模型。
消息处理流程
多个 socket 可能会并发产生不同的操作，每个操作对应不同的文件事件，但是 IO多路复用程序会监听多个 socket，会将产生事件的 socket 顺序、每次一个放入队列中排队，并且在一个事件执行结束后才放另一个事件，事件分派器每次从队列中取出一个 socket，根据 socket 的事件类型交给对应的事件处理器进行处理。
尽管多个文件事件可能会并发地出现，但I/O多路复用程序总是会将所有产生事件的套接字都推到一个队列里面，然后通过这个队列，以有序（sequentially）、同步（synchronously）、每次一个套接字的方式向文件事件分派器传送套接字：当上一个套接字产生的事件被处理完毕之后（该套接字为事件所关联的事件处理器执行完毕）， I/O多路复用程序才会继续向文件事件分派器传送下一个套接字。
I/O 多路复用程序的实现
Redis的I/O多路复用程序的所有功能是通过包装select、epoll、evport和kqueue这些I/O多路复用函数库来实现的，每个I/O多路复用函数库在Redis源码中都对应一个单独的文件，比如ae_select.c、ae_epoll.c、ae_kqueue.c等。因为Redis为每个I/O多路复用函数库都实现了相同的API，所以I/O多路复用程序的底层实现是可以互换的。
文件事件的类型
I/O 多路复用程序可以监听多个套接字的ae.h/AE_READABLE事件和ae.h/AE_WRITABLE事件，这两类事件和套接字操作之间的对应关系如下：
-
当套接字变得可读时（客户端对套接字执行write操作，或者执行close操作），或者有新的可应答（acceptable）套接字出现时（客户端对服务器的监听套接字执行connect操作），套接字产生AE_READABLE 事件。
-
当套接字变得可写时（客户端对套接字执行read操作），套接字产生AE_WRITABLE事件。I/O多路复用程序允许服务器同时监听套接字的AE_READABLE事件和AE_WRITABLE事件，如果一个套接字同时产生了这两种事件，那么文件事件分派器会优先处理AE_READABLE事件，等到AE_READABLE事件处理完之后，才处理AE_WRITABLE 事件。这也就是说，如果一个套接字又可读又可写的话，那么服务器将先读套接字，后写套接字。
文件事件的处理器
Redis为文件事件编写了多个处理器，这些事件处理器分别用于实现不同的网络通讯需求，常用的处理器如下：
- 为了对连接服务器的各个客户端进行应答， 服务器要为监听套接字关联连接应答处理器。
- 为了接收客户端传来的命令请求， 服务器要为客户端套接字关联命令请求处理器。
- 为了向客户端返回命令的执行结果， 服务器要为客户端套接字关联命令回复处理器。
连接应答处理器
连接应答处理器用于对连接服务器监听套接字的客户端进行应答，具体实现为sys/socket.h/accept函数的包装。
当Redis服务器进行初始化的时候，程序会将这个连接应答处理器和服务器监听套接字的AE_READABLE事件关联起来，当有客户端用sys/socket.h/connect函数连接服务器监听套接字的时候， 套接字就会产生AE_READABLE 事件， 引发连接应答处理器执行， 并执行相应的套接字应答操作。
命令请求处理器
命令请求处理器负责从套接字中读入客户端发送的命令请求内容， 具体实现为unistd.h/read函数的包装。
当一个客户端通过连接应答处理器成功连接到服务器之后， 服务器会将客户端套接字的AE_READABLE事件和命令请求处理器关联起来，当客户端向服务器发送命令请求的时候，套接字就会产生 AE_READABLE事件，引发命令请求处理器执行，并执行相应的套接字读入操作。
在客户端连接服务器的整个过程中，服务器都会一直为客户端套接字的AE_READABLE事件关联命令请求处理器。
命令回复处理器
命令回复处理器负责将服务器执行命令后得到的命令回复通过套接字返回给客户端，具体实现为unistd.h/write函数的包装。
当服务器有命令回复需要传送给客户端的时候，服务器会将客户端套接字的AE_WRITABLE事件和命令回复处理器关联起来，当客户端准备好接收服务器传回的命令回复时，就会产生AE_WRITABLE事件，引发命令回复处理器执行，并执行相应的套接字写入操作。
当命令回复发送完毕之后， 服务器就会解除命令回复处理器与客户端套接字的 AE_WRITABLE 事件之间的关联。
一次完整的客户端与服务器连接事件示例
假设Redis服务器正在运作，那么这个服务器的监听套接字的AE_READABLE事件应该正处于监听状态之下，而该事件所对应的处理器为连接应答处理器。
如果这时有一个Redis客户端向Redis服务器发起连接，那么监听套接字将产生AE_READABLE事件， 触发连接应答处理器执行：处理器会对客户端的连接请求进行应答， 然后创建客户端套接字，以及客户端状态，并将客户端套接字的 AE_READABLE 事件与命令请求处理器进行关联，使得客户端可以向主服务器发送命令请求。
之后，客户端向Redis服务器发送一个命令请求，那么客户端套接字将产生 AE_READABLE事件，引发命令请求处理器执行，处理器读取客户端的命令内容， 然后传给相关程序去执行。
执行命令将产生相应的命令回复，为了将这些命令回复传送回客户端，服务器会将客户端套接字的AE_WRITABLE事件与命令回复处理器进行关联：当客户端尝试读取命令回复的时候，客户端套接字将产生AE_WRITABLE事件， 触发命令回复处理器执行， 当命令回复处理器将命令回复全部写入到套接字之后， 服务器就会解除客户端套接字的AE_WRITABLE事件与命令回复处理器之间的关联。
