Web服务器主要任务就是处理来自客户端的请求，一般情况下Web服务器处理并发连接请求的工作模型有以下几种方式：
1、单线程web服务器(Single-threaded web servers)
此种架构方式中，web服务器一次处理一个请求，结束后读取并处理下一个请求。在某请求处理过程中，其它所有的请求将被忽略，因此，在并发请求较多的场景中将会出现严重的性能问题。（即一次只能处理一个请求）
2、多进程/多线程web服务器
此种架构方式中，web服务器生成多个进程或线程并行处理多个用户请求，进程或线程可以按需或事先生成。有的web服务器应用程序为每个用户请求生成一个单独的进程或线程来进行响应，不过，一旦并发请求数量达到成千上万时，多个同时运行的进程或线程将会消耗大量的系统资源。（即每个进程只能响应一个请求，并且一个进程对应一个线程）
3、I/O多路复用web服务器
为了能够支持更多的并发用户请求，越来越多的web服务器正在采用多种复用的架构———即同步监控所有的连接请求的活动状态，当一个连接的状态发生改变时(如数据准备完毕或发生某错误)，将为其执行一系列特定操作；在操作完成后，此连接将重新变回暂时的稳定态并返回至打开的连接列表中，直到下一次的状态改变。由于其多路复用的特性，进程或线程不会被空闲的连接所占用，因而可以提供高效的工作模式。（这种架构可以理解为一个进程可以生成多个线程，每个请求交给一个线程进行处理）
4、多路复用多线程web服务器
将多进程和多路复用的功能结合起来形成的web服务器架构，其避免了让一个进程服务于过多的用户请求，并能充分利用多CPU主机所提供的计算能力。（这种架构可以理解为有多个进程，并且一个进程又生成多个线程，每个线程处理一个请求）
linux下常用的I/O模型（这里借用下在网上查阅的资料，感觉还好理解）：
先引入select和epoll概念：
select和epoll是两个处理I/O模型的机制，可以加速请求处理，2者处理方式不同：通俗的讲，select机制是对没有处理好的I/O请求在一段时间内进行检测，并将其状态通知给用户，即有没有完成都会通知。而epool机制则是在该I/O请求完成后才通知给用户。
在Unix/Linux下共有五种I/O模型，分别是：
1）阻塞I/O
2）非阻塞I/O
3）I/O复用（select和poll）
4）信号驱动I/O（SIGIO）
5）异步I/O（Posix.1的aio_系列函数）
对以上模型的比较：
阻塞I/O：
应用程序调用一个IO函数，导致应用程序阻塞，等待数据准备好。 如果数据没有准备好，一直等待….数据准备好了，从内核拷贝到用户空间,IO函数返回成功指示
非阻塞I/O:
我们把一个套接口设置为非阻塞就是告诉内核，当所请求的I/O操作无法完成时，不要将进程睡眠，而是返回一个错误。这样我们的I/O操作函数将不断的测试数据是否已经准备好，如果没有准备好，继续测试，直到数据准备好为止。在这个不断测试的过程中，会大量的占用CPU的时间。
I/O复用（select和poll）:
I/O复用模型会用到select或者poll函数，这两个函数也会使进程阻塞，但是和阻塞I/O所不同的的，这两个函数可以同时阻塞多个I/O操作。而且可以同时对多个读操作，多个写操作的I/O函数进行检测，直到有数据可读或可写时，才真正调用I/O操作函数。
信号驱动I/O（SIGIO）:
首先我们允许套接口进行信号驱动I/O,并安装一个信号处理函数，进程继续运行并不阻塞。当数据准备好时，进程会收到一个SIGIO信号，可以在信号处理函数中调用I/O操作函数处理数据。
异步I/O（Posix.1的aio_系列函数）:
当一个异步过程调用发出后，调用者不能立刻得到结果。实际处理这个调用的部件在完成后，通过状态、通知和回调来通知调用者的输入输出操作
回顾下apache的工作模块：
prefork：多进程，每个请求用一个进程响应，这个过程会用到select机制来通知。
worker：多进程，一个进程可以生成多个线程，每个线程响应一个请求。
event：一个进程，每个进程响应多个用户请求，它是基于事件实现的。
基于事件机制的特性：