RedisIO多路复用

一、多路复用要解决的问题:

并发多客户端连接，在多路复用之前的处理方案是同步阻塞网络IO模型，这种模型的特点就是用一个进程来处理一个网络连接。优点在于比较简单，缺点在于性能较差，每个用户请求到来都得占用一个进程来处理，来一个请求就要分配一个进程跟进处理；最好是使用一个进程处理多个连接请求

可以采用Linux提供的IO多路复用机制，这里的复用指的就是对进程的复用

多路是指多个客户端连接，指的是多条TCP连接，复用是指用一个进程处理多条的连接，使用单进程就能够实现同时处理多个客户端的连接；实现了一个进程处理大量的用户连接。IO多路复用类似一个规范和接口，落地实现；

二、Redis单线程是如何处理多并发连接:

Redis利用epoll实现IO多路复用，将连接信息和事件放到队列中，一次放到文件事件分派器，事件分派器将事件分发给事件处理器

Redis 是跑在单线程中的，所有的操作都是按照顺序线性执行的，但是由于读写操作等待用户输入或输出都是阻塞的，所以 I/O 操作在一般情况下往往不能直接返回，这会导致某一文件的IO阻塞，进而导致整个进程无法对其他客户提供服务，而IO多路复用就是为了解决这个问题而出现；

所谓IO多路复用机制，就是通过一种机制可以监视多个描述符，一旦某个描述符就绪(一般是读就绪或写就绪)，能够通知程序进行相应的读写操作。这种机制的使用需要select 、 poll、 epoll来配合。多个连接共用一个阻塞对象，应用程序只需要在一个阻塞对象上等待，无需阻塞等待所有连接。当某条连接有新的数据可以处理时，操作系统通知应用程序，线程从阻塞状态返回，开始进行业务处理。

Redis服务采用Reactor的方式来实现文件事件处理器(每一个网络连接其实都对应一个文件描述符)；Redis基于Reactor模式开发了网络事件处理器，这个处理器被称为文件事件处理器。它的组成结构为4部分:多个套接字、IO多路复用程序、文件事件分派器以及事件处理器，因为文件事件分派器队列的消费是单线程的，所以Redis才叫做单线程模型

三、Unix网络编程中的IO模型:

同步:调用者要一直等待调用结果的通知后才能进行后续的执行；

异步:被调用方先返回应答让调用者先回去，然后再计算调用结果，计算完最终结果后再通知并返回给调用方；一般需要通过回调获得结果

阻塞:调用方一直在等待而别的事情都不做

非阻塞:调用在发出后调用方先去忙别的事情，不会阻塞当前进程/线程，而会立即返回

(1).阻塞IO(Blocking IO,BIO):

当用户进程调用了recvfrom这个系统调用，kernel就开始了IO的第一个阶段:准备数据(对于网络IO来说，很多时候数据在一开始还没有到达;比如还没有收到一个完整的UDP包。这个时候kernel就要等待足够的数据到来)。这个过程需要等待，也就是说数据被拷贝到操作系统内核的缓冲区中是需要一个过程的。

而在用户进程这边，整个进程会被阻塞(当然，是进程自己选择的阻塞)。当kernel一直等到数据准备好了，它就会将数据从kernel中拷贝到用户内存，然后kernel返回结果，用户进程才解除block的状态，重新运行起来。所以，BIO的特点就是在IO执行的两个阶段都被block了。

可以利用多线程，只要连接了一个socket，操作系统分配一个线程来处理，这样read()方法堵塞在每个具体线程上而不堵塞主线程，就能操作多个socket了，哪个线程中的socket有数据，就读哪个socket，各取所需，灵活统一。程序服务端只负责监听是否有客户端连接，使用accept()阻塞；客户端1连接服务端，就开辟一个线程(thread1)来执行 read()方法，程序服务端继续监听；客户端2连接服务端，也开辟一个线程(thread2)来执行read()方法，程序服务端继续监听；任何一个线程上的socket有数据发送过来，read()就能立马读到，cpu就能进行处理

多线程模型的缺点在于每来一个客户端就要开辟一个线程，如果来1万个客户端，那就要开辟1万个线程。在操作系统中用户态不能直接开辟线程，需要调用内核来创建的一个线程，这其中还涉及到用户状态的切换(上下文的切换)，十分耗资源。可以通过使用线程池或者使用NIO(非阻塞IO)的方式解决

(2)非阻塞IO(No Blocking IO):

当用户进程发出read操作时，如果kernel中的数据还没有准备好，那么它并不会block用户进程，而是立刻返回一个erorr;从用户进程角度讲,它发起一个read操作后，并不需要等待，而是马上就得到了一个结果。用户进程判断结果是一个erorr时，它就知道数据还没有准备好，于是它可以再次发送read操作。一旦kernel中的数据准备好了，并且又再次收到了用户进程的system call，那么它马上就将数据拷贝到了用户内存,然后返回。所以，NIO特点是用户进程需要不断的主动询问内核数据是否准备好

在NIO模式中，一切都是非阻塞的；accept()方法是非阻塞的，如果没有客户端连接，就返回无连接标识；read()方法是非阻塞的，如果read()方法读取不到数据就返回空闲中标识，如果读取到数据时只阻塞read()方法读数据的时间

在NIO模式中，只有一个线程:当一个客户端与服务端进行连接，这个socket就会加入到一个数组中，隔一段时间遍历一次，看这个socket的read()方法能否读到数据，这样一个线程就能处理多个客户端的连接和读取

NIO成功的解决了BIO需要开启多线程的问题，一个线程就能解决多个socket，不会阻塞在内核的等待过程，每次发起的IO请求可以立即返回，不用阻塞等待，实时性较好；缺点在于轮询将不断地询问内核，这将占用大量地CPU时间，系统资源利用率较低。

(3).IO Multiplexing(IO多路复用):

IO Multipexing指的是在单个线程通过记录跟踪每一个sock地状态来同时管理多个IO流，目的是尽量多的提高服务器的吞吐能力

IO multiplexing就是我们说的select,poll,epoll;有些技术书籍也称这种IO方式为event driven IO事件驱动IO。就是通过一种机制，一个进程可以监视多个描述符，一旦某个描述符就绪(一般是读就绪或者写就绪)，能够通知程序进行相应的读写操作。可以基于一个阻塞对象并同时在多个描述符上等待就绪，而不是使用多个线程(每个文件描述符一个线程，每次new一个线程)，这样可以大大节省系统资源。所以，IO多路复用的特点是通过一种机制一个进程能同时等待多个文件描述符而这些文件描述符(套接字描述符)其中的任意一个进入读就绪状态,select，poll，epoll等所数就可以返回。

a.select函数:

select其实就是把NIO中用户态要遍历的fd数组(我们的每一个socket链接，安装进ArrayList里面的那个)拷贝到了内核态,让内核态来遍历，因为用户态判断socket是否有数据还是要调用内核态的，所有拷贝到内核态后，这样遍历判断的时候就不用一直用户态和内核态频繁切换

select函数存在一些缺点，首先bitmap最大1024位，一个进程最多只能处理1024个客户端；其次&rset不可重用，每次socket有数据就相应的位会被置位；另外文件描述符数组拷贝到了内核态(只不过无系统调用切换上下文的开销。(内核层可优化为异步事件通知))，仍然有开销。select调用需要传入fd数组，需要拷贝一份到内核，高并发场景下这样的拷贝消耗的资源是惊人的。(可优化为不复制)；最后select并没有通知用户态哪一个socket有数据，仍然需要O(n)的遍历。select仅仅返回可读文件描述符的个数，具体哪个可读还是要用户自己遍历。(可优化为只返回给用户就绪的文件描述符，无需用户做无效的遍历)

select方式既做到了一个线程处理多个客户端连接(文件描述符)，又减少了系统调用的开销(多个文件描述符只有一次 select 的系统调用 +N次就绪状态的文件描述符的read系统调用)

b.poll函数:

c.epoll函数:

三种方法的对比:

(4).Reactor模式:

Reactor 模式，是指通过一个或多个输入同时传递给服务处理器的服务请求的事件驱动处理模式。服务端程序处理传入多路请求，并将它们同步分派给请求对应的处理线程，Reactor 模式也叫 Dispatcher 模式。即I/O多了复用统一监听事件，收到事件后分发(Dispatch 给某进程)，是编写高性能网络服务器的必备技术;

Reactor 模式中有 2 个关键组成:

a.Reactor:Reactor 在一个单独的线程中运行，负责监听和分发事件，分发给适当的处理程序来对IO事件做出反应。 

b.Handlers:处理程序执行IO事件要完成的实际事件，类似于客户想要与之交谈的公司中的实际办理人。Reactor通过调度适当的处理程序来响应I/O事件，处理程序执行非阻塞操作。

四、五种IO模型总结: