今天这篇主要是聊一些关于nginx中一些进程的管理，信号的传递，还有就是如何进行事件的处理的一些东西。

nginx进程

nginx主要的进程为master、work、cache。master是用来管理work进程的，所以master是不会有第三方模块进入代码的，它主要是管理work进程的状态，还有就是监测work进程是否需要文件重新载入，需不需要热部署；而work是用来处理正常的工作；缓存是在多个work之间进行共享的，cache manager（缓存管理）和cache loader（缓存的载入）是为了反向代理时后端请求做缓存使用的，实际上每个请求使用的缓存还是由work进程来进行，这些进程之间的通信都是由共享内存处理的。

那么为什么采用多进程结构而不是多线程结构呢？这是因为Nginx最核心的功能是要保证它的高可靠性、高可用性，如果Nginx采用多线程结构的时候，因为线程之间共享的是同一个地址空间的，如果某一个第三方模块引发的地址空间越界时会导致整个Nginx挂掉，而多进程不会出现这个情况。

刚才说到nginx会有master节点和work节点，这是因为Nginx采用了事件驱动的模型之后，希望每个work进程独占一颗CPU，往往不只需要将Nginx的work进程配置的和CPU核数相同，还要和CPU的某个核绑定在一起，这样是为了更好的使用CPU上面的缓存，减少CPU缓存的失效数。

nginx信号管理

在master进程中，主要是有两个信号的操作，一个是监控work进程，另一个是管理work进程。

首先是监控work进程，主要的动作是查看work进程有没有发送CHLD信号，Linux操作系统中规定当子进程终止的时候会向父进程发送CHLD信号。当work意外终止时，master进程会通过CHLD信号快速知道这个事件。然后重新把work进程拉起。

管理worker进程，主要有以下信号：

TERM, INT 立刻停止Nginx进程

QUIT 优雅的退出进程

HUP 重载配置文件

USR1 重新打开日志文件，作为日志切割

USR2 只能通过kill直接向master信号，作为热部署使用

WINCH 只能通过kill直接向master信号，作为热部署使用

对于work进程的信号主要是以下几种：

TERM, INT 立刻停止Nginx进程

QUIT 优雅的退出进程

USR1 重新打开日志文件，作为日志切割

WINCH 只能通过kill直接向master信号，作为热部署使用

当然通常情况下不会对work进程直接发送信号，都是通过master进程来控制work进程，当我们向master发送指令的时候master进程会通过信号向work进程发送信号。

Nginx命令行

reload：HUP

reopen：USR1

stop：TERM

quit：QUIT

nginx的pid存放在logs目录下的nginx.pid 目录中，这个文件存放master进程的pid当我们向nginx发送命令的时候，nginx会去找自己的pid然后找到master进程的pid最终实现我们的命令。

nginx的请求处理流程

首先是三种状态机，第一种是处理TCP/UDP四层协议的传输层状态机；第二种是处理应用层协议HTTP请求的状态机；第三种是处理邮件的状态机。nginx主要是通过这三种状态机来处理事件的。那么有个问题是nginx为什么使用状态机来处理事件呢?因为Nginx的时间处理是异步IO模型来处理事件，通常我们使用异步IO模型处理事件是需要状态机将请求正确处理和识别的。异步IO是一种非阻塞事件处理。

当我们需要访问静态资源的时候状态机会识别并指向静态资源，如果我们访问反向代理的时候也要去磁盘中读取，如果内存不能缓存所有的静态资源的时候回退化成阻塞的处理，所以需要一个线程池，将所有的请求记录到日志中去。更多的时候我们的Nginx是作为负载均衡和反向代理的，我们的Nginx可以通过HTTP等协议将数据传到后台。