BIO-select-epoll个人总结 + redis线程模型

先讲一下最简单的情况：

BIO+单client。

先是server启动服务并监听，然后client连接server，此时创建一个线程，并在内核生成文件描述符fd6，同时线程会调用recvfrom等待消息，如下图所示：

然后，client1发送数据，数据最终会到fd6上。此时线程就能读取到对应的数据，对数据进行处理后将结果返回给client1。

客户端当然不会只有一个，因此需要建立多个线程来进行处理。

BIO+多client。

如下图所示：当有三个客户端连接服务器，就需要有三个线程来分别对三个文件描述符（fd6,fd7,fd8）进行处理，另外，我们是可以使用线程池来管理多线程的。

虽然可以使用线程池对线程进行管理，提高效率，但客户端越来越多时，终究不能通过无限制地增加线程这一方式来解决问题。因此需要使用一种方式来管理多个文件描述符，也就是I/O多路复用。

I/O多路复用之select

服务器应用程序可以使用select来同时管理多个文件描述符（fds），只会这样就可以有效地控制线程的数量。但是select自身存在着明显的缺陷（这里不阐述），所以后来就出现了epoll方法。

I/O多路复用之epoll

应用：redis线程模型

首先，redis为什么要用单线程：https://cloud.tencent.com/developer/article/1120615

redis采用了单reactor单线程模式，也就是单线程中包含一个dispathcer分发器和多个handler处理器。

具体模型：
首先，redis创建socket服务端，生成一个名为server socket的套接字（文件描述符）。
客户端连接redis时，socket server套接字内会产生一个AE_READABLE的文件事件，事件会被IO多路复用程序监听，IO多路服用可以有select、epoll等，一般是epoll。
就绪的事件会被epoll出来然后放入一个队列中，这样就可以按照一定顺序分发给事件分派器dispatcher，不同的事件会分发给不同的handler（处理器），比方说本次的连接请求就会被分发到连接应答处理器。
建立连接后，redis会生成与客户端对应的套接字（文件描述符）socket1，之后客户端向redis发送的请求时，会在socket1中产生AE_READABLE的文件事件，然后最后会被分发给命令请求处理器。
客户端试图读取命令回复（询问是否有结果了）时，客户端套接字产生 AE_WRITEABLE 事件，触发命令回复处理器将命令回复全部写入到客户端对应的套接字中。

详见：https://blog.youkuaiyun.com/y277an/article/details/98342442