多路I/O复用模型，非阻塞IO

下面举一个例子，模拟一个tcp服务器处理30个客户socket。 假设你是一个监考老师，让30个学生解答一道竞赛考题，然后负责验收学生答卷，你有下面几个选择：

1. 第一种选择：按顺序逐个验收，先验收A，然后是B，之后是C、D。。。这中间如果有一个学生卡住，全班都会被耽误。 这种模式就好比，你用循环挨个处理socket，根本不具有并发能力。
2. 第二种选择：你创建30个分身，每个分身检查一个学生的答案是否正确。 这种类似于为每一个用户创建一个进程或者线程处理连接。
3. 第三种选择，你站在讲台上等，谁解答完谁举手。这时C、D举手，表示他们解答问题完毕，你下去依次检查C、D的答案，然后继续回到讲台上等。此时E、A又举手，然后去处理E和A。。。 这种就是IO复用模型，Linux下的select、poll和epoll就是干这个的。将用户socket对应的fd注册进epoll，然后epoll帮你监听哪些socket上有消息到达，这样就避免了大量的无用操作。此时的socket应该采用非阻塞模式。 这样，整个过程只在调用select、poll、epoll这些调用的时候才会阻塞，收发客户消息是不会阻塞的，整个进程或者线程就被充分利用起来，这就是事件驱动，所谓的reactor模式。【epoll监听哪些socket上有事件到达，当 accept、read、write 和 close 文件事件产生时，就会回调 FD 绑定的事件处理器】

 

有30个redis客户端（考生）与redis服务器的网络连接模块（监考老师）保持TCP连接，客户端会不定时的发送请求给服务器，当有一个redis客户端发起请求，会触发unix系统像epoll这样的系统调用，Redis的I/O 多路复用模块封装了底层的epoll这样的 I/O 多路复用函数，然后转发到相应的事件处理器。

文件事件处理器使用 I/O 多路复用模块同时监听多个 FD（文件描述符），当 accept、read、write 和 close 文件事件产生时，文件事件处理器就会回调 FD 绑定的事件处理器。

虽然整个文件事件处理器是在单线程上运行的，但是通过 I/O 多路复用模块的引入，实现了同时对多个 FD 读写的监控，提高了网络通信模型的性能，同时也可以保证整个 Redis 服务实现的简单。