就最新版本的Web服务器Apache2.4来说，一共有三种稳定的MPM（Multi-Processing Module，多进程处理模块）模式。它们分别是prefork，worker和event，它们同时也代表这Apache的演变和发展。
首先简单介绍一下prefork、worker、event三种工作模式：
prefork，多进程模式，1个进程服务于1个用户请求，成本比较高。但是，稳定性最高，不需要支持线程安全。
worker，多进程多线程模式，1个进程含有多个worker线程，1个worker线程服务于1个用户请求，因为线程更轻量，成本比较低。但是，在KeepAlive场景下，worker资源会被client占据，无法响应其他请求（空等待）。
event，多进程多线程模式，1个进程也含有多个worker线程，1个worker线程服务于1个用户请求。但是，它解决了KeepAlive场景下的worker线程被占据问题，它通过专门的线程来管理这些KeepAlive连接，然后再分配“工作”给具体处理的worker，工作worker不会因为KeepAlive而导致空等待。
查看我们Apache的模式，可以使用httpd -V命令来查看：
[root@localhost ~]# httpd -V
Server version: Apache/2.4.23 (Unix)
Server built: Nov 15 2016 10:43:13
Server's Module Magic Number: 20120211:61
Server loaded: APR 1.5.2, APR-UTIL 1.5.4
Compiled using: APR 1.5.2, APR-UTIL 1.5.4
Architecture: 64-bit
Server MPM: event
编译的时候，可以通过configure的参数来指定：
--with-mpm=prefork|worker|event
也可以编译为三种都支持，通过修改配置来更换:
--enable-mpms-shared=all
在httpd.conf中修改Apache的多处理模式MPM可以通过（modules文件夹下，会自动编译出三个MPM的so）：
#LoadModule mpm_prefork_module modules/mod_mpm_prefork.so
#LoadModule mpm_worker_module modules/mod_mpm_worker.so
LoadModule mpm_event_module modules/mod_mpm_event.so
1. mpm_prefork模式
prefork模式可以算是很古老但是非常稳定的Apache模式。Apache在启动之初，就预先fork一些子进程，然后等待请求进来。之所以这样做，是为了减少频繁创建和销毁进程的开销。每个子进程只有一个线程，在一个时间点内，只能处理一个请求。
优点：成熟稳定，兼容所有新老模块。同时，不需要担心线程安全的问题。（我们常用的mod_php，PHP的拓展不需要支持线程安全）
缺点：一个进程相对占用更多的系统资源，消耗更多的内存。而且，它并不擅长处理高并发请求，在这种场景下，它会将请求放进队列中，一直等到有可用进程，请求才会被处理。
Apache2.4在/etc/httpd/extra/httpd-manual.conf中配置参数（httpd.conf默认没有启用，需要#Include /etc/httpd/extra/httpd-mpm.conf取消这行的注释，重启httpd）：
<IfModule mpm_prefork_module>
StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxRequestWorkers 250
MaxConnectionsPerChild 0
</IfModule>
2. mpm_worker模式
worker模式比起上一个，是使用了多进程和多线程的混合模式。它也预先fork了几个子进程（数量比较少），然后每个子进程创建一些线程，同时包括一个监听线程。每个请求过来，会被分配到1个线程来服务。线程比起进程会更轻量，因为线程通常会共享父进程的内存空间，因此，内存的占用会减少一些。在高并发的场景下，因为比起prefork有更多的可用线程，表现会更优秀一些。
有些人会觉得奇怪，那么这里为什么不完全使用多线程呢，还要引入多进程？
原因主要是需要考虑稳定性，如果一个线程异常挂了，会导致父进程连同其他正常的子线程都挂了（它们都是同一个进程下的）。为了防止这场异常场景出现，就不能全部使用线程，使用多个进程再加多线程，如果某个线程出现异常，受影响的只是Apache的一部分服务，而不是整个服务。
优点：占据更少的内存，高并发下表现更优秀。
缺点：必须考虑线程安全的问题，因为多个子线程是共享父进程的内存地址的。如果使用keep-alive的长连接方式，某个线程会一直被占据，也许中间几乎没有请求，需要一直等待到超时才会被释放。如果过多的线程，被这样占据，也会导致在高并发场景下的无服务线程可用。（该问题在prefork模式下，同样会发生）
注：keep-alive的长连接方式，是为了让下一次的socket通信复用之前创建的连接，从而，减少连接的创建和销毁的系统开销。保持连接，会让某个进程或者线程一直处于等待状态，即使没有数据过来。
也是在/etc/httpd/extra/httpd-manual.conf中设置参数：
<IfModule mpm_worker_module>
StartServers 3
MinSpareThreads 75
MaxSpareThreads 250
ThreadsPerChild 25
MaxRequestWorkers 400
MaxConnectionsPerChild 0
</IfModule>
3. mpm_event模式
这个是Apache中最新的模式，在现在版本里的已经是稳定可用的模式。它和worker模式很像，最大的区别在于，它解决了keep-alive场景下，长期被占用的线程的资源浪费问题（某些线程因为被keep-alive，空挂在哪里等待，中间几乎没有请求过来，甚至等到超时）。event MPM中，会有一个专门的线程来管理这些keep-alive类型的线程，当有真实请求过来的时候，将请求传递给服务线程，执行完毕后，又允许它释放。这样增强了高并发场景下的请求处理能力。
event MPM在遇到某些不兼容的模块时，会失效，将会回退到worker模式，一个工作线程处理一个请求。官方自带的模块，全部是支持event MPM的。
注意一点，event MPM需要Linux系统（Linux 2.6+）对EPoll的支持，才能启用。
还有，需要补充的是HTTPS的连接（SSL），它的运行模式仍然是类似worker的方式，线程会被一直占用，知道连接关闭。部分比较老的资料里，说event MPM不支持SSL，那个说法是几年前的说法，现在已经支持了。
同样也在/etc/httpd/extra/httpd-manual.conf中设置参数：
<IfModule mpm_event_module>
StartServers 3
MinSpareThreads 75
MaxSpareThreads 250
ThreadsPerChild 25
MaxRequestWorkers 400
MaxConnectionsPerChild 0
</IfModule>
三种模式下，我通过ab做了一下性能测试，在常规满负载的场景下，并未发现有大的差异。
测试语句：
ab -k -c 200 -n 200000 http://www.amd5.cn/index.html
测试结果：
prefork：9556QPS
worker ：11038QPS
event ：10224QPS
测试语句：
ab -k -c 200 -n 200000 http://www.amd5.cn/index.php（echo "hello world";）
测试结果：
prefork：6094QPS
worker ：7411QPS
event ：7089QPS
就使用PHP而言，fastCGI和php-fpm是更推荐的使用模式。
现在的最新浏览器，在单个域名下的连接数变得越来越多（通常都是使用keep-alive），主流浏览器是2-6个（还有继续增长趋势，为了加快页面的并发下载速度）。高并发场景，会越来越成为Web系统的一种常态。Apache很成熟，同时也背负了比较重的历史代码和模块，因此，在Web系统比较方面，Nginx在不少场景下，表现比起Apache更为出色。
