apache的MPM三种机制：prefork，worker，event

Multi-Processing Module：多进程处理模块
特别说明：对于prefork，worker，event三种稳定机制，event机制是在2.2版本或者更高版本才有的，2.2版本中只是实验性的支持，2.4版本是完全支持的。


1 prefork MPM
为了减少频繁创建和销毁进程的开销，在apache启动之初，就预先fork部分子进程，用来等待请求，每个子进程只对应一个线程，在一个时间点内，
只处理一个请求；
优点：一个进程相对占用更多的系统资源，消耗更多的内存,兼容新旧模块并且线程十分安全；
缺点：不能很好的处理高并发请求，在此种情况下，它会将请求放进队列中，一直等到有可用的进程，请求才会被处理；



    StartServers              启动的子进程的个数
    MinSpareServers           最少空闲进程数
    MaxSpareServers           最大空闲进程数
    MaxRequestWorkers         并发请求的最大数
    MaxConnectionsPerChild    每个子进程在生命周期内所能够服务的最多连接个数，0表示不限定



2 worker
它也预先fork了几个子进程（数量比较少），然后每个子进程创建一些线程，同时包括一个监听线程。每个请求过来，会被分配到1个线程来服务。
线程比起进程会更轻量，因为线程通常会共享父进程的内存空间，因此，内存的占用会减少一些。在高并发的场景下，相对prefork有更多的
可用线程，效率上相对要好些。
那么这里为什么不完全使用多线程呢，还要引入多进程？
原因主要是需要考虑稳定性，由于，它们都在同一个父进程下，如果一个线程异常挂了，会导致父进程连同其他正常的子线程都挂了。为了
避免此异常场景，因而是用多个进程和多线程，这样，如果某个线程出现异常，受影响的只是其中一部分服务，而不是整个服务。


优点：占据更少的内存，高并发下表现更优秀。
缺点：必须考虑线程安全的问题，因为多个子线程是共享父进程的内存地址的。如果使用keep-alive的长连接方式，某个线程会一直被占据，
期间没有请求，需要一直等到超时才会被释放,如果过多的线程，被这样占据，也会导致在高并发场景下的无服务线程可用。
（该问题在prefork模式下，同样会发生）
注：keep-alive的长连接方式，是为了让下一次的socket通信复用之前创建的连接，从而，减少连接的创建和销毁的系统开销。保持连接，
会让某个进程或者线程一直处于等待状态，即使没有数据过来。
;
    StartServers              启动的子进程的个数
    MinSpareThreads           最小空闲线程数
    MaxSpareThreads           最大空闲线程数 
    ThreadsPerChild           每个子进程可生成的线程数
    MaxRequestWorkers         并发请求的最大数
    MaxConnectionsPerChild    每个子进程在生命周期内所能够服务的最多连接个数，0表示不限定
;


3 event
此种模式解决了keep-alive场景下，线程占用资源浪费的问题，event MPM中，会有一个专门的线程来管理这些keep-alive类型的线程，
当有请求时，将请求传递给服务线程，执行完毕后，又允许它释放，提高了高并发场景下的请求处理能力。event MPM支持HTTPS的连接（SSL）。


如下代码注释同上

    StartServers             
    MinSpareThreads         
    MaxSpareThreads        
    ThreadsPerChild         
    MaxRequestWorkers      
    MaxConnectionsPerChild