Apache 和 NGINX 的工作特点介绍

Apache 的 prefork 模式：

Apache 在 prefork 模式下启动后，会由父进程创建监听端口（IP + 端口），并根据配置预先创建一定数量的子进程。

父进程主要负责管理这些子进程，本身不参与具体请求处理，真正处理请求的是子进程。

当客户端发起请求时，会由空闲的子进程去处理该请求。每个子进程同一时间只能处理一个请求，在处理过程中该进程是阻塞的，也就是说它不能再去处理其他请求，只有等当前请求处理完后，才会重新变为空闲状态。

每个子进程可以根据配置，在处理一定数量的请求后退出并重新创建，以避免长期运行带来的内存问题。

如果并发请求较高，比如只有 10 个子进程，但同时来了 1000 个请求，那么前 10 个请求会被立即处理，剩下的请求会进入内核的等待队列中排队等待；如果排队数量超过限制，那么新的请求就会被拒绝。

可以把它类比为一个公司：1 个老板（父进程）+ 10 个员工（子进程），每个员工一次只能处理一件事，如果事情太多，就需要排队，排不下就只能拒绝。

因此，prefork 模式是通过增加子进程数量来提升并发能力，但在高并发场景下会带来较高的内存消耗和上下文切换开销。

Apache 的 event 模式

event 模式是 worker 模式的增强版，worker 模式是一个进程开多个线程，然后每个线程去处理一个请求，但是有个问题就是请求处理完了，但连接还没断（keep-alive），此时请求处理完了，但连接还没断（keep-alive）。就相当于员工处理完事，还要陪客户聊天（keepalive）。

所以就在 worker 的基础上提出了 event 这种工作模式，这种模式的特点在于线程处理完请求后，把这个连接交给事件机制（epoll），然后再去处理下一个请求。就相当于员工办完事后，让前台继续陪客户，不要影响员工工作。

NGINX 工作模式的特点：

NGINX 没有 Apache 那么多的工作模式，启动后由 Master 进程负责管理子进程并创建监听端口。随后会根据 CPU 核心数启动多个 Worker 进程来处理请求（通过配置文件指定），每个 Worker 进程通常是单线程的。

当有请求到来时，由某个 Worker 进程通过事件机制（如 epoll）进行处理。Worker 并不会为每个请求创建线程，也不会一次性把一个请求处理完再处理下一个，而是采用事件驱动的方式进行分段处理：处理一部分后，如果需要等待 IO（如网络或磁盘），就把该连接交给 epoll 继续监听，然后去处理其他就绪的请求。这样，一个 Worker 进程就可以同时处理大量连接，让每个请求都能及时得到响应。

可以类比为一个公司：1 个老板（Master）+ 多个员工（Worker），但每个员工并不是只服务一个客户，而是同时轮流处理很多客户，谁有需求就先处理谁。