多处理模块(MPM) Apache HTTP 服务器被设计为一个功能强大，并且灵活的 web 服务器， 可以在很多平台与环境中工作。不同平台和不同的环境往往需要不同的特性，或可能以不同的方式实现相同的
多处理模块(MPM)
Apache HTTP 服务器被设计为一个功能强大，并且灵活的 web 服务器， 可以在很多平台与环境中工作。不同平台和不同的环境往往需要不同的特性，或可能以不同的方式实现相同的特性最有效率。Apache httpd 通过模块化的设计来适应各种环境。这种设计允许网站管理员通过在 编译时或运行时，选择哪些模块将会加载在服务器中，来选择服务器特性。
Apache HTTP 服务器 2.0 扩展此模块化设计到最基本的 web 服务器功能。 它提供了可以选择的多处理模块(MPM)，用来绑定到网络端口上，接受请求， 以及调度子进程处理请求。
扩展到这一级别的服务器模块化设计，带来两个重要的好处:
- Apache httpd 能更优雅，更高效率的支持不同的平台。尤其是 Apache httpd 的 Windows 版本现在更有效率了，因为
mpm_winnt能使用原生网络特性取代在 Apache httpd 1.3 中使用的 POSIX 层。它也可以扩展到其它平台 来使用专用的 MPM。 - Apache httpd 能更好的为有特殊要求的站点定制。例如，要求 更高伸缩性的站点可以选择使用线程的 MPM，即
worker或event； 需要可靠性或者与旧软件兼容的站点可以使用prefork。
在用户看来，MPM 很像其它 Apache httpd 模块。主要是区别是，在任何时间， 必须有一个，而且只有一个 MPM 加载到服务器中。
在全部平台中，MPM 都可以构建为静态模块。在构建时选择一种 MPM，链接到服务器中。如果要改变 MPM，必须重新构建。
为了使用指定的 MPM，请在执行 configure 脚本 时，使用参数 --with-mpm=NAME。NAME 是指定的 MPM 名称。
编译完成后，可以使用 ./httpd -l 来确定选择的 MPM。 此命令会列出编译到服务器程序中的所有模块，包括 MPM。
./httpd -l 和 ./httpd -V 选项都可以看出当前选用的 MPM 的模式
Apache的三种 MPM 模式
三种稳定的MPM（Multi-Processing Module，多进程处理模块）模式。它们分别是prefork，worker和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并在 httpd.conf 中添加 Include conf/extra/httpd-mpm.conf，httpd-mpm.conf 中包含了 MPM 的有关配置；
1、prefork MPM
prefork 模式可以算是很古老但是非常稳定的 Apache 模式。Apache 在启动之初，就预先 fork 一些子进程，然后等待请求进来。之所以这样做，是为了减少频繁创建和销毁进程的开销。每个子进程只有一个线程，在一个时间点内，只能处理一个请求。
- 优点：成熟稳定，兼容所有新老模块。同时，不需要担心线程安全的问题。（我们常用的mod_php，PHP 的拓展不需要支持线程安全）
- 缺点：一个进程相对占用更多的系统资源，消耗更多的内存。而且，它并不擅长处理高并发请求，在这种场景下，它会将请求放进队列中，一直等到有可用进程，请求才会被处理。
prefork 模式在 httpd-mpm.conf 中的默认配置：
<IfModule mpm_prefork_module> StartServers 5 MinSpareServers 5 MaxSpareServers 10 MaxRequestWorkers 250 MaxConnectionsPerChild 0</IfModule>2、worker MPM
worker 模式比起上一个，是使用了多进程和多线程的混合模式。它也预先 fork 了几个子进程（数量比较少），然后每个子进程创建一些线程，同时包括一个监听线程。每个请求过来，会被分配到 1 个线程来服务。线程比起进程会更轻量，因为线程通常会共享父进程的内存空间，因此，内存的占用会减少一些。在高并发的场景下，因为比起 prefork 有更多的可用线程，表现会更优秀一些。
有些人会觉得奇怪，那么这里为什么不完全使用多线程呢，还要引入多进程？
原因主要是需要考虑稳定性，如果一个线程异常挂了，会导致父进程连同其他正常的子线程都挂了（它们都是同一个进程下的）。为了防止这场异常场景出现，就不能全部使用线程，使用多个进程再加多线程，如果某个线程出现异常，受影响的只是 Apache 的一部分服务，而不是整个服务。
- 优点：占据更少的内存，高并发下表现更优秀。
- 缺点：必须考虑线程安全的问题，因为多个子线程是共享父进程的内存地址的。如果使用 keep-alive 的长连接方式，某个线程会一直被占据，也许中间几乎没有请求，需要一直等待到超时才会被释放。如果过多的线程，被这样占据，也会导致在高并发场景下的无服务线程可用。（该问题在 prefork 模式下，同样会发生）
注：keep-alive 的长连接方式，是为了让下一次的 socket 通信复用之前创建的连接，从而，减少连接的创建和销毁的系统开销。保持连接，会让某个进程或者线程一直处于等待状态，即使没有数据过来。
worker 模式在 httpd-mpm.conf 中的默认配置：
<IfModule mpm_worker_module> StartServers 3 MinSpareThreads 75 MaxSpareThreads 250 ThreadsPerChild 25 MaxRequestWorkers 400 MaxConnectionsPerChild 0</IfModule>3、event MPM
这个是 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，那个说法是几年前的说法，现在已经支持了。
event 模式在 httpd-mpm.conf 中的默认配置：
<IfModule mpm_event_module> StartServers 3 MinSpareThreads 75 MaxSpareThreads 250 ThreadsPerChild 25 MaxRequestWorkers 400 MaxConnectionsPerChild 0</IfModule>
生产环境 Apache MPM 优化
生产环境接入层硬件配置：
4 台 8 核 16G 内存阿里云 VPC ECS实际压测统计 httpd 消耗内存大约每个 httpd 进程在 2M 左右：
[root@iZ23s96w2paZ ~]# ps -ylC httpd --sort:rss | awk '{sum+=$8; ++n} END {print "Tot="sum"("n")";print "Avg="sum"/"n"="sum/n/1024"MB"}'Tot=1106968(503)Avg=1106968/503=2.23159MB预留 5G 内存给 Apache 使用，同时为了避免在 apache 在 fork 进程等操作消耗，保留足够的工作进程，由于没有兼容性相关的测试，生产环境选用最原始的 profork 模式，配置如下：
<IfModule mpm_prefork_module> StartServers 500 ServerLimit 2500 MinSpareServers 500 MaxSpareServers 1000 MaxRequestWorkers 2000 MaxConnectionsPerChild 0</IfModule>
