共计 946 个字符，预计需要花费 3 分钟才能阅读完成。
今天有一件高兴的事要跟大家分享，果子博客重新整顿风格后，人气一直飙升，今天早上起来一看，已经 10K+ 访问量了，这都离不开大家的支持，由于时间关系，今天我只跟大家分享下 Nginx 工作进程处理关系图，后续将更新 Nginx 配置解析模块。
运行中的 Nginx 进程间的关系
首先我们来看一副图再作讲解：
在上一节中，我们提到了 Nginx 的 master 进程，即 Nginx 的 “ 管理员 ” 进程，它的进程 ID 有且仅有一个，它仅专注于自己的纯管理工作，即管理它的 worker 进程，当做生意一个对外提供服务的 worker 进程出现错误从而导致 coredump 时，master 进程会立刻启动新的 worker 进程继续服务；此外，它还可以为管理员提供命令行服务，包括前面小节中提到的向 Nginx 发送信号、启动服务、停止服务、重载配置文件、平滑升级等。通常情况下它是以 root 用户启动或编译选项中指定的用户来启动。
多个 worker 进程处理互联网请求不但可以提高服务的健壮性 —— 一个 worker 进程出错后，其它 worker 进程仍然可以提供服务，事实上，它最重要的功能在于，可以充分利用现在觉的 SMP 多核架构，从而实现微观上真正的多核并发处理，所以，在 Nginx 的配置文件中有一个配置项 work_processes number, 其中 number 为指定的进程数，一般为 CPU 的核数，worker_cpu_affinity 配置项为绑定 CPU 的核数，以下为一个简单的配置组合：
work_processes 4;
worker_cpu_affinity 1000 0100 0010 0001;
这里，我们可以拿另一个 WEB 服务器 Apache 来作比较，Apache 上每个进程在同一时刻只能处理一个请求，因此，如果希望 WEB 服务器拥有更多的并发请求，就要把 Apache 的进程或线程数设置的更多，通过一台服务器拥有几百个工作进程，这样在并发请求时，大量的进程间切换将带来巨大的系统资源消耗。
而 Nginx 则不同，一个 worker 进程可以同时处理的请求数只受限于内存大小，而且在架构设计上，不同的 worker 进程之间处理并发请求时几乎没有同步锁的限制，也不会进入睡眠状态，当 Nginx 上的进程数与 CPU 核心数相等时，进程间的切换代价是最小的。
