什么是I/O多路复用、事件驱动、reactor模式

在讲解该技术之前，我们需要预习一下文件以及文件描述符。

什么是文件

程序员使用I/O最终都逃不过文件这个概念。

在Linux世界中文件是一个很简单的概念，作为程序员我们只需要将其理解为一个N byte的序列就可以了：

b1, b2, b3, b4, … bN

实际上所有的I/O设备都被抽象为了文件这个概念，一切皆文件，Everything is File，磁盘、网络数据、终端，甚至进程间通信工具管道pipe等都被当做文件对待。

所有的I/O操作也都可以通过文件读写来实现，这一非常优雅的抽象可以让程序员使用一套接口就能对所有外设I/O操作。

常用的I/O操作接口一般有以下几类：

• 打开文件，open
• 改变读写位置，seek
• 文件读写，read、write
• 关闭文件，close

程序员通过这几个接口几乎可以实现所有I/O操作，这就是文件这个概念的强大之处。

文件描述符

之前说过，要想进行I/O读操作，像磁盘数据，我们需要指定一个buff用来装入数据，一般都是这样写的：

read(buff);

但是这里我们忽略了一个关键问题，那就是虽然我们指定了往哪里写数据，但是我们该从哪里读数据呢？

从上一节中我们知道，通过文件这个概念我们能实现几乎所有I/O操作，因此这里少的一个主角就是文件。

那么我们一般都怎样使用文件呢？

如果周末你去比较火的餐厅吃饭应该会有体会，一般周末人气高的餐厅都会排队，然后服务员会给你一个排队序号，通过这个序号服务员就能找到你，这里的好处就是服务员无需记住你是谁、你的名字是什么、来自哪里、喜好是什么、是不是保护环境爱护小动物等等，这里的关键点就是服务员对你一无所知，但依然可以通过一个号码就能找到你。

同样的，在Linux世界要想使用文件，我们也需要借助一个号码，这个号码就被称为了文件描述符，file descriptors，在Linux世界中鼎鼎大名，其道理和上面那个排队号码一样。

因此，文件描述仅仅就是一个数字而已，但是通过这个数字我们可以操作一个打开的文件，这一点要记住。

有了文件描述符，进程可以对文件一无所知，比如文件在磁盘的什么位置、加载到内存中又是怎样管理的等等，这些信息统统交由操作系统打理，进程无需关心，操作系统只需要给进程一个文件描述符就足够了。

因此我们来完善上述程序：

int fd = open(file_name); // 获取文件描述符read(fd, buff);

怎么样，是不是非常简单。

文件描述符太多了怎么办

经过了这么多的铺垫，终于要到高性能、高并发这一主题了。

从前几节我们知道，所有I/O操作都可以通过文件样的概念来进行，这当然包括网络通信。

如果你有一个web服务器，当三次握手成功以后，我们会调用accept来获取一个链接，调用该函数我们同样会得到一个文件描述符，通过这个文件描述符就可以处理客户端发送的请求并且把处理结果发送回去。也就是说通过这个描述符我们就可以和客户端进行通信了。

通过accept获取客户端的文件描述符int conn_fd = accept(...)

server的处理逻辑通常是读取客户端请求数据，然后执行某些特定逻辑：

if(read(conn_fd, request_buff) > 0) {   
	 do_something(request_buff);
}

是不是非常简单，然而世界终归是复杂的，当然也不是这么简单的。

接下来就是比较复杂的了。

既然我们的主题是高并发，那么server就不可能只和一个客户端通信，而是可能会同时和成千上万个客户端进行通信。这时你需要处理不再是一个描述符这么简单，而是有可能要处理成千上万个描述符。

为了不让问题一上来就过于复杂，我们先简单化，假设只同时处理两个客户端的请求。

有的同学可能会说，这还不简单，这样写不就行了：

if(read(socket_fd1, buff) > 0) {
 	// 处理第一个    
 	do_something();
 }
 if(read(socket_fd2, buff) > 0) {
 	 // 处理第二个    
 	 do_something();
 }

以前我们讨论过这是非常典型的阻塞式I/O，如果此时没有数据可读那么进程会被阻塞而暂停运行，这时我们就无法处理第二个请求了，即使第二个请求的数据已经就位，这也就意味着处理某一个客户端时由于进程被阻塞导致剩下的所有其它客户端必须等待，在同时处理几万客户端的server上，这显然是不能容忍的。

聪明的你一定会想到使用多线程，为每个客户端请求开启一个线程，这样一个客户端被阻塞就不会影响到处理其它客户端的线程了，注意，既然是高并发，那么我们要为成千上万个请求开启成千上万个线程吗，大量创建销毁线程会严重影响系统性能。

那么这个问题该怎么解决呢？

这里的关键点在于，我们事先并不知道一个文件描述对应的I/O设备是否是可读的、是否是可写的，在外设的不可读或不可写的状态下进行I/O只会导致进程阻塞被暂停运行。

因此要优雅的解决这个问题，就要从其它角度来思考这个问题了。

不要打电话给我，有需要我会打给你

大家生活中肯定会接到过推销电话，而且不止一个，一天下来接上十个八个推销电话你的身体会被掏空的。

这个场景的关键点在于打电话的人并不知道你是不是要买东西，只能来一遍遍问你，因此一种更好的策略是不要让他们打电话给你，记下他们的电话，有需要的话打给他们，这样推销员就不会一遍一遍的来烦你了(虽然现实生活中这并不可能)。

在这个例子中，你，就好比内核，推销者就好比应用程序，电话号码就好比文件描述符，和你用电话沟通就好比I/O。

现在你应该明白了吧，处理多个文件描述符的更好方法其实就存在于推销电话中。

因此相比上一节中我们通过I/O接口主动问内核这些文件描述符对应的外设是不是已经就绪了，一种更好的方法是，我们把这些感兴趣的文件描述符一股脑扔给内核，并霸气的告诉内核：“我这里有1万个文件描述符，你替我监视着它们，有可以读写的文件描述符时你就告诉我，我好处理”。而不是弱弱的问内核：“第一个文件描述可以读写了吗？第二个文件描述符可以读写吗？第三个文件描述符可以读写了吗？。。。”

这样应用程序就从“繁忙”的主动变为了清闲的被动，反正文件描述可读可写了内核会通知我，能偷懒我才不要那么勤奋。
比如监控100个文件描述符，用户线程问内核是不是准备好了，内核自己用内核线程来轮询这100个描述符（阻塞IO是用户自己轮询）一旦有1个准备好了，这个用户线程就处理这个；
如果100个都没有准备好，那用户线程还是阻塞的！！！

这是一种更加高效的I/O处理机制，现在我们可以一次处理多路I/O了，为这种机制起一个名字吧，就叫I/O多路复用吧，这就是 I/O multiplexing。

I/O多路复用，I/O multiplexing

multiplexing一词其实多用于通信领域，为了充分利用通信线路，希望在一个信道中传输多路信号，要想在一个信道中传输多路信号就需要把这多路信号结合为一路，将多路信号组合成一个信号的设备被称为multiplexer，显然接收方接收到这一路组合后的信号后要恢复原先的多路信号，这个设备被称为demultiplexer，如图所示：

回到我们的主题。

所谓I/O多路复用指的是这样一个过程：

1. 我们拿到了一堆文件描述符(不管是网络相关的、还是磁盘文件相关等等，任何文件描述符都可以)

2. 通过调用某个函数告诉内核：“这个函数你先不要返回，你替我监视着这些描述符，当这堆文件描述符中有可以进行I/O读写操作的时候你再返回”（这个函数调用的时候，内核就会用内核线程来监听这些描述符）

3. 当调用的这个函数返回后我们就能知道哪些文件描述符可以进行I/O操作了。

也就是说通过I/O多路复用我们可以同时处理多路I/O。那么有哪些函数可以用来进行I/O多路复用呢？

在Linux世界中有这样三种机制可以用来进行I/O多路复用：

• select
• poll
• epoll

接下来我们就来介绍一下牛掰的I/O多路复用三剑客。

I/O多路复用三剑客

本质上select、poll、epoll都是阻塞式I/O，也就是我们常说的同步I/O，原因在于调用这些I/O多路复用函数时如果所有监控的描述符都不可读\写那么进程会被阻塞暂停执行，直到有文件描述符可读或者可写才继续运行。

1，select：初出茅庐

在select这种I/O多路复用机制下，我们需要把想监控的文件描述集合通过函数参数的形式告诉select，然后select会将这些文件描述符集合拷贝到内核中(描述符原来是在用户线程空间，现在内核线程要监控，所有要拷贝到内核线程空间)，我们知道数据拷贝是有性能损耗的，因此为了减少这种数据拷贝带来的性能损耗，Linux内核对集合的大小做了限制，并规定用户监控的文件描述集合不能超过1024个，同时当select返回后我们仅仅能知道有些文件描述符可以读写了，但是我们不知道是哪一个，因此程序员必须再遍历一边找到具体是哪个文件描述符可以读写了。

因此，总结下来select有这样几个特点：

• 我能照看的文件描述符数量有限，不能超过1024个
• 用户给我的文件描述符需要拷贝的内核中
• 我只能告诉你有文件描述符满足要求了，但是我不知道是哪个，你自己一个一个去找吧(遍历)

因此我们可以看到，select机制的这些特性在高并发网络服务器动辄几万几十万并发链接的场景下无疑是低效的。

2，poll：小有所成

poll和select是非常相似的，poll相对于select的优化仅仅在于解决了文件描述符不能超过1024个的限制，select和poll都会随着监控的文件描述数量增加而性能下降，因此不适合高并发场景。

3，epoll：独步天下

在select面临的三个问题中，文件描述数量限制已经在poll中解决了，剩下的两个问题呢？

针对拷贝问题，epoll使用的策略是各个击破与共享内存。

实际上文件描述符集合的变化频率比较低，select和poll频繁的拷贝整个集合，内核都快被烦死了，epoll通过引入epoll_ctl很体贴的做到了只操作那些有变化的文件描述符，同时epoll和内核还成为了好朋友，共享了同一块内存，这块内存中保存的就是那些已经可读或者可写的的文件描述符集合，这样就减少了内核和程序的拷贝开销。

针对需要遍历文件描述符才能知道哪个可读可写这一问题，epoll使用的策略是“当小弟”。

在select和poll机制下，进程要亲自下场去各个文件描述符上等待，任何一个文件描述可读或者可写就唤醒进程，但是进程被唤醒后也是一脸懵逼并不知道到底是哪个文件描述符可读或可写，还要再从头到尾检查一遍。

但epoll就懂事多了，主动找到进程要当小弟替大哥出头。

在这种机制下，进程不需要亲自下场了，进程只要等待在epoll上，epoll代替进程去各个文件描述符上等待，当哪个文件描述符可读或者可写的时候就告诉epoll，epoll用小本本认真记录下来然后唤醒大哥：“进程大哥，快醒醒，你要处理的文件描述符我都记下来了”，这样进程被唤醒后就无需自己从头到尾检查一遍，因为epoll小弟都已经记下来了。

因此我们可以看到，在epoll这种机制下，实际上利用的就是“不要打电话给我，有需要我会打给你”这种策略，进程不需要一遍一遍麻烦的问各个文件描述符，而是翻身做主人了，“你们这些文件描述符有哪个可读或者可写了主动报上来”，这种机制实际上就是大名鼎鼎的事件驱动，Event-driven，这也是我们下一篇的主题。

实际上在Linux平台，epoll基本上就是高并发的代名词。

基于一切皆文件的设计哲学，I/O也可以通过文件的形式实现，高并发场景下要与多个文件交互，这就离不开高效的I/O多路复用技术，本文我们详细讲解了什么是I/O多路复用以及使用方法，这其中以epoll为代表的I/O多路复用(基于事件驱动)技术使用非常广泛，实际上你会发现但凡涉及到高并发、高性能的场景基本上都能见到事件驱动的编程方法。

转载2

首先，要从常用的IO操作谈起，比如read和write，通常IO操作都是阻塞I/O的，也就是说当你调用read时，如果没有数据收到，那么线程或者进程就会被挂起，直到收到数据。

这样，当服务器需要处理1000个连接的的时候，而且只有很少连接忙碌的，那么会需要1000个线程或进程来处理1000个连接，而1000个线程大部分是被阻塞起来的。由于CPU的核数或超线程数一般都不大，比如4,8,16,32,64,128，比如4个核要跑1000个线程，那么每个线程的时间槽非常短，而线程切换非常频繁。

这样是有问题的：
（1）线程是有内存开销的，1个线程可能需要512K（或2M）存放栈，那么1000个线程就要512M（或2G）内存。线程的切换，
（2）或者说上下文切换是有CPU开销的，当大量时间花在上下文切换的时候，分配给真正的操作的CPU就要少很多。

那么，我们就要引入非阻塞I/O的概念，非阻塞IO很简单，通过fcntl（POSIX）或ioctl（Unix）设为非阻塞模式，这时，当你调用read时，如果有数据收到，就返回数据，如果没有数据收到，就立刻返回一个错误。这样是不会阻塞线程了，但是你还是要不断的轮询来读取或写入。

于是，我们需要引入IO多路复用的概念。多路复用是指使用一个线程来检查多个文件描述符（Socket）的就绪状态，比如调用select和poll函数，传入多个文件描述符，如果有一个文件描述符就绪，则返回，否则阻塞直到超时。得到就绪状态后进行真正的操作可以在同一个线程里执行，也可以启动线程执行（比如使用线程池）。
这样在处理1000个连接时，只需要1个线程监控就绪状态，对就绪的每个连接开一个线程处理就可以了，这样需要的线程数大大减少，减少了内存开销和上下文切换的CPU开销。

直白点说： select/epoll函数就是多路复用器(multiplexing)

1. 早期的socket服务器是这样的：核心是一个线程处理一个socket。

ClientSocket s = accept(ServerSocket);  // 阻塞
   new Thread(s,function(){
         while( have data) {
            s.read(); // 阻塞
            s.send('xxxx');
         }
         s.close();
   });  

2. 核心是一个线程处理一个socket。

ClientSocket s = accept(ServerSocket);  // 阻塞
  waitting_set.add(s); 
  while(1) {
     set_have_data  ds = select(waitting_set); // 多路复用器，
                                               // 多路复用是说多个socket数据通路
                                               // 一个select就可以侦听
                                               // 就好像他们是一个数据通路一样。
     foreach(ds as item) {
          item.read();  // reactor这里不会阻塞，采用异步io，详情查linux aio
          item.send('xxx');
     }
      item.close();
  }

可以看到，第一，一个线程就完成了n个socket的读写，第二，多了select语句。event-driven/proactor/reactor 好处：

避免大量的线程创建工作，每个线程的创建工作都要消耗系统资源，比如每个线程至少要1M内存来维持其存在，32位的机器，不用thread pool，并发4千就挂了。线程多了难免会更多的发生线程切换（context switch），线程切换要保存线程的stack，register，如果是进程切换，要清cpu的L1 cache，MMU的TLB，使得系统不必要的开销过大。

下面举一个例子，模拟一个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模式。