传统Unix并发的解决方案（为每一个新的连接fork()一个子进程）比较适合以下的情况：并发量很小并且计算的工作量远大于一个fork(）的开销，但这种方案情况比较适合长连接，不太适合短连接，并发量大时这种模式也无法满足，因此不太适合本项目。
对传统Unix并发方案差的一种小改进是thread per connection（即为每一个连接分配一个线程），这种方案比起上一种在一些场景下会好一些，比如thread的开销通常比fork()小的时候（在windows下进程开销很大，在linux下thread和fork的开销差不多），或者进程间需要有数据通讯时（进程间数据通讯很麻烦，而线程由于共享地址空间和数据空间，可以直接互相访问数据，注意写的时候要加锁）。但是，这个解决方案依然存在着一样的问题，适合长连接，不太适合短连接，无法解决高并发量下的情况。
现代服务器编程模式普遍采用reactor模式， reactor设计模式，是一种基于事件驱动的设计模式。Reactor框架是ACE各个框架中最基础的一个框架，其他框架都或多或少地用到了Reactor框架。在事件驱动的应用中，将一个或多个客户的服务请求分离（demultiplex）和调度（dispatch）给应用程序。在事件驱动的应用中，同步地、有序地处理同时接收的多个服务请求。 在reactor模式中，IO复用模型有3种，select，poll，epoll，虽然epoll在大部分情况下性能表现都远优于select和poll，但在低并发的情况下select比epoll会快一些，下面简单介绍下这3种IO复用模型，借此说明下为什么要选择epoll作为本项目的IO复用模型。
1.select
selcect的调用过程如下：
（1）使用copy_from_user从用户空间拷贝fd_set到内核空间
（2）注册回调函数__pollwait
（3）遍历所有fd，调用其对应的poll方法（对于socket，这个poll方法是sock_poll，sock_poll根据情况会调用到tcp_poll,udp_poll或者datagram_poll）
（4）以tcp_poll为例，其核心实现就是__pollwait，也就是上面注册的回调函数。
（5）__pollwait的主要工作就是把current（当前进程）挂到设备的等待队列中，不同的设备有不同的等待队列，对于tcp_poll来说，其等待队列是sk->sk_sleep（注意把进程挂到等待队列中并不代表进程已经睡眠了）。在设备收到一条消息（网络设备）或填写完文件数据（磁盘设备）后，会唤醒设备等待队列上睡眠的进程，这时current便被唤醒了。
（6）poll方法返回时会返回一个描述读写操作是否就绪的mask掩码，根据这个mask掩码给fd_set赋值。
（7）如果遍历完所有的fd，还没有返回一个可读写的mask掩码，则会调用schedule_timeout是调用select的进程（也就是current）进入睡眠。当设备驱动发生自身资源可读写后，会唤醒其等待队列上睡眠的进程。如果超过一定的超时时间（schedule_timeout指定），还是没人唤醒，则调用select的进程会重新被唤醒获得CPU，进而重新遍历fd，判断有没有就绪的fd。
（8）把fd_set从内核空间拷贝到用户空间。
select存在几大缺点：
（1）每次调用select，都需要把fd集合从用户态拷贝到内核态，这个开销在fd很多时会很大
（2）同时每次调用select都需要在内核遍历传递进来的所有fd，这个开销在fd很多时也很大
（3）select支持的文件描述符数量太小了，默认是1024
2 poll
poll的实现和select非常相似，只是描述fd集合的方式不同，poll使用pollfd结构而不是select的fd_set结构，其他的都差不多。总的来说，poll 去掉了select中1024个链接的限制，于是要多少链接呢， 主人你开心就好。poll 从设计上来说，不再修改传入数组，不过这个要看你的平台了。但依然还是存在着高并发时轮询效率低下的问题。
3、epoll
epoll既然是对select和poll的改进，就应该能避免上述的三个缺点。那epoll都是怎么解决的呢？在此之前，我们先看一下epoll和select和poll的调用接口上的不同，select和poll都只提供了一个函数——select或者poll函数。而epoll提供了三个函数，epoll_create,epoll_ctl和epoll_wait，epoll_create是创建一个epoll句柄；epoll_ctl是注册要监听的事件类型；epoll_wait则是等待事件的产生。
对于第一个缺点，epoll的解决方案在epoll_ctl函数中。每次注册新的事件到epoll句柄中时（在epoll_ctl中指定EPOLL_CTL_ADD），会把所有的fd拷贝进内核，而不是在epoll_wait的时候重复拷贝。epoll保证了每个fd在整个过程中只会拷贝一次。
对于第二个缺点，epoll的解决方案不像select或poll一样每次都把current轮流加入fd对应的设备等待队列中，而只在epoll_ctl时把current挂一遍（这一遍必不可少）并为每个fd指定一个回调函数，当设备就绪，唤醒等待队列上的等待者时，就会调用这个回调函数，而这个回调函数会把就绪的fd加入一个就绪链表）。epoll_wait的工作实际上就是在这个就绪链表中查看有没有就绪的fd（利用schedule_timeout()实现睡一会，判断一会的效果，和select实现中的第7步是类似的）。
对于第三个缺点，epoll没有这个限制，它所支持的FD上限是最大可以打开文件的数目，这个数字一般远大于2048,举个例子,在1GB内存的机器上大约是10万左右，具体数目可以cat /proc/sys/fs/file-max察看,一般来说这个数目和系统内存关系很大。
说到这里，再提一下epoll的ET工作模式（edge trigger边缘模式）和LT工作模式（level trigger电平模式），这两种模式有一定的区别，首先，默认情况下epoll是工作在LT模式下的，LT模式下既支持block模式，也支持non-block模式，ET模式下只支持non-block模式，ET模式是更高效的模式，它高效在哪呢？LT模式下，当epoll_wait函数检测到有事件发生并将通知应用程序，而应用程序不一定必须立即进行处理，这样epoll_wait函数再次检测到此事件的时候还会通知应用程序，直到事件被处理。而ET模式，只要epoll_wait函数检测到事件发生，通知应用程序立即进行处理，后续的epoll_wait函数将不再检测此事件。因此ET模式在很大程度上降低了同一个事件被epoll触发的次数，因此效率比LT模式高。举个例子说明，当服务器端的fd收到“OK”这个字符串时，epoll_wait会通知该fd就绪，在LT模式下，不对这个fd进行处理，在下一个循环中epoll_wait还是会通知该fd就绪，而在ET模式下，该fd只会通知一次，也就是说，第一次不进行处理的话，该fd就不会再通知了，ET模式强制编写代码时每次都对fd进行处理。
总结一下这3种模型的优缺点：
（1）select，poll实现需要自己不断轮询所有fd集合，直到设备就绪，期间可能要睡眠和唤醒多次交替。而epoll其实也需要调用epoll_wait不断轮询就绪链表，期间也可能多次睡眠和唤醒交替，但是它是设备就绪时，调用回调函数，把就绪fd放入就绪链表中，并唤醒在epoll_wait中进入睡眠的进程。虽然都要睡眠和交替，但是select和poll在“醒着”的时候要遍历整个fd集合，而epoll在“醒着”的时候只要判断一下就绪链表是否为空就行了，这节省了大量的CPU时间。这就是回调机制带来的性能提升。
（2）select，poll每次调用都要把fd集合从用户态往内核态拷贝一次，并且要把current往设备等待队列中挂一次，而epoll只要一次拷贝，而且把current往等待队列上挂也只挂一次（在epoll_wait的开始，注意这里的等待队列并不是设备等待队列，只是一个epoll内部定义的等待队列）。这也能节省不少的开销。
因此，本项目采用epoll作为IO复用的模型（也不是说epoll就是绝对的高效，如果并发数量小而且每个连接都比较活跃，那么select可能会更高效一点）。
仅靠epoll就可以完成一个简单的支持高并发的服务器（在我的GitHub上有一个简单的用epoll实现的支持高并发的echo服务器，网址https://github.com/zk3326312/EpollServer/），但这样的服务器存在以下问题：如果你想修改业务逻辑，那么你就需要去修改网络部分的代码，这样非常不利于代码的扩展，如果想将业务代码抽象出来，就需要依靠reactor模式。因此，我们可以知道这种模式比起thread per connection和for per connection有以下几个优点：
1.支持高并发，能处理大量的用户连接。
2.epoll需配合非阻塞IO使用，因此，这种方案适合IO密集型的应用。
3.结合reactor模式可以将业务逻辑抽象出来，利于代码扩展。
单线程的reactor处理高并发和IO密集的任务时可以有很好的表现，但并没有发挥出现在服务器设备的多核优势，大量的用户连接时服务器的连接处理能力可能会有所下降，因此，本项目采用的是reactors in threads的方案，用一个main reactors来处理连接请求，连接成功后就将其挂载在一个sub reactors中，这和muduo和netty的方案是一样的（如果你的线程间彼此没有很多信息交互，那么采用Nginx的reactors in processes也是很好的）。总的方案框架图如下：
