Apache的三种工作模式

Apache的三种工作模式分别为：prefork，worker，event
在Unix系统中，父进程通常以root身份运行以便绑定80端口，而 Apache产生的子进程通常以一个低特权的用户运行。User和Group指令用于配置子进程的低特权用户。运行子进程的用户必须要对他所服务的内容有读取的权限，但是对服务内容之外的其他资源必须拥有尽可能少的权限。
分别说说这三个模式：
Prefork
apache最早的一个模式，它的工作方式是，在apache启动的时候，就会预派生一些子进程，然后等待请求进来。当消耗一些进程时，它又会再预派生一些子进程。（之所以这样做，是为了在请求进来的时候，可以直接调用进程，而不需要再生成进程，从而节省开销。）
它总是试图准备一些备用的子进程。（该备用的子进程的数量配置文件中设定）
在该工作模式下，一个进程只含有一个线程，一个线程对应一个请求。

优点：成熟，兼容所有新老模块。进程之间完全独立，使得它非常稳定。同时，不需要担心线程安全的问题。（我们常用的mod_php，PHP的拓展不需要支持线程安全）

缺点：一个进程相对占用更多的系统资源，消耗更多的内存。而且，它并不擅长处理高并发请求，在这种场景下，它会将请求放进队列中，一直等到有可用进程，请求才会被处理。

    #服务器启动时建立的子进程数量
    StartServers          5 

    #空闲子进程的最小数量，默认5；如果当前空闲子进程数少于MinSpareServers ，那么Apache将会产生新的子进程。此参数不要设的太大。
    MinSpareServers       5  

    #空闲子进程的最大数量，默认10；如果当前有超过MaxSpareServers数量的空闲子进程，那么父进程会杀死多余的子进程。此参数也不需要设置太大，如果你将其设置比 MinSpareServers 小，Apache会自动将其修改为MinSpareServers+1。
    MaxSpareServers      10

    #限定服务器同一时间内客户端最大接入的请求数量，默认是150；任何超过了该限制的请求都要进入等待队列，一旦一个个连接被释放，队列中的请求才将得到服务。
    MaxClients          150

    #每个子进程在其生命周期内允许最大的请求数量，如果请求总数已经达到这个数值，子进程将会结束，如果设置为0，子进程将永远不会结束。若该值设置为非0值，可以防止运行PHP导致的内存泄露。
    MaxRequestsPerChild   0

Worker MPM
该工作模式下，每个子进程能够生成一些服务线程和一个监听线程，该监听线程监听接入请求并将其传递给服务线程处理和应答。
线程比起进程会更轻量，因为线程通常会共享父进程的内存空间，因此，内存的占用会减少一些，在高并发的场景下，表现得比 prefork模式好。但，它存在一个缺点，当一个线程挂掉时候，会导致该线程所在的进程直接挂掉（包括该进程的其余健康线程）

优点：占据更少的内存，高并发下表现更优秀。

缺点：必须考虑线程安全的问题，因为多个子线程是共享父进程的内存地址的。如果使用keep-alive的长连接方式，也许中间几乎没有请求，这时就会发生阻塞，线程被挂起，需要一直等待到超时才会被释放。如果过多的线程，被这样占据，也会导致在高并发场景下的无服务线程可用。（该问题在prefork模式下，同样会发生）

Ps：http1.1的keep-alive的长连接方式，是为了让下一次的socket通信复用之前创建的连接，从而，减少连接的创建和销毁的系统开销。保持连接，会让某个进程或者线程一直处于等待状态，即使没有数据过来。

    #服务器启动时建立的子进程数量
    StartServers          2

    #限定服务器同一时间内客户端最大接入的请求数量，默认是150；任何超过了该限制的请求都要进入等待队列，一旦一个个连接被释放，队列中的请求才将得到服务。
    MaxClients          150

    #空闲子进程的最小数量
    MinSpareThreads      25

    #空闲子进程的最大数量
    MaxSpareThreads      75 

    #每个子进程产生的线程数量
    ThreadsPerChild      25

    #每个子进程在其生命周期内允许最大的请求数量，如果请求总数已经达到这个数值，子进程将会结束，如果设置为0，子进程将永远不会结束。将该值设置为非0值，可以防止运行PHP导致的内存泄露。
    MaxRequestsPerChild   0

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，那个说法是几年前的说法，现在已经支持了。

    #服务器启动时建立的子进程数量
    StartServers             3

    #空闲子进程的最小数量
    MinSpareThreads         75

    #空闲子进程的最小数量
    MaxSpareThreads        250

    #每个子进程产生的线程数量
    ThreadsPerChild         25

    #限定服务器同一时间内客户端最大接入的请求数量，默认是150；任何超过了该限制的请求都要进入等待队列，一旦一个个连接被释放，队列中的请求才将得到服务。
    MaxRequestWorkers      400

    #每个子进程在其生命周期内允许最大的请求数量，如果请求总数已经达到这个数值，子进程将会结束，如果设置为0，子进程将永远不会结束。将该值设置为非0值，可以防止运行PHP导致的内存泄露。
    MaxRequestsPerChild   0