nginx请求处理流程及进程结构

1， nginx请求处理流程

大致有三种流量，进入nginx中，nginx中有三种大的状态机，处理tcp/udp的传输层状态机，处理应用层的http状态机，处理邮件的mail状态机(叫状态机是因为nginx中核心的绿色的框是用非阻塞的事件驱动处理引擎，一旦使用这种异步处理引擎后，通常要用状态机来把请求正确的识别和处理)，基于这样的事件状态处理机，我们在解析出请求需要访问静态资源时，可以看到走左下方的箭头去找静态资源，做反向代理时，对反向代理的内容也可以做磁盘缓存，但是当内存不足以缓存静态资源信息时，会退化成阻塞的线程调用，所以要有线程池来进行处理，对于每一个处理完成的请求，我们会记录access日志和error日志。更多的时候，nginx作为负载均衡和反向代理来使用，这时我们可以把请求通过协议传输到后面的服务器，也可以通过应用层的一些协议代理到响应的应用服务器

2， nginx的进程结构

其实有单进程结构和多进程结构，单进程结构不适用于生产环境，只适用于开发，因为在生产环境中，我们必须报保持nginx足够健壮以及nginx可以利用多核的特性，单进程做不到这一点，所以默认都是打开多进程nginx

Nginx进程架构如下：

会有一个父进程叫master process ，他有很多子进程，分为两类，一类叫worker进程，一类叫cache相关的进程。由master作为父进程，启动许多子进程，且nginx的进程之间是通过信号进行管理的

为什么采用多进程而不是多线程呢？

核心目的：nginx要保证它的高可用性和高可靠性，而当nginx使用了多线程结构时，因为线程之间是共享同一个地址空间的，所以当某一个第三方模块引发了一个地址空间导致的断错误时，地址越界出现时，会导致整个nginx全部挂掉，而多进程就不会出现这样的问题

高可用与高可靠的体现：
比如在master中，通常第三方模块是不会在这里加入自己的功能代码的，虽然nginx在设计时允许第三方模块在master进程中添加自己独有的自定义的方法，但是通常没有第三模块这样做，master进程是用来做worker进程的管理的，也就是说所有的worker进程是用来处理真正的请求的，master进程负责监控每个worker进程是不是在正常的工作，需不需要重新载入配置文件，需不需要热部署，缓存是要在多个进程间共享的，不仅要被work进程使用，还要被cache loader ，cache manager使用，这两者为反向代理时后端发来的动态请求缓存所使用的，cache loader 做缓存的载入，cache manager做缓存的管理，实际上每个请求用到的缓存还是由worker进程来进行的，这些进程间的通讯都是使用共享内存来解决的

为什么有这么多work进程？

Nginx采用了事件驱动的模型以后，他希望每一个work进程从头到尾占用一颗cpu，所以往往我们除了把work进程的配置与我们服务器上的cpu核数一致以外，还需要把每一个worker进程和每一颗cpu绑定在一起，这样可以更好的使用每一颗cpu核上的cpu缓存来减少缓存失效的命中率

3， 实例演示

ps –ef | grep nginx

用-s reload ，将之前的work进程包括cache进程优雅的退出，然后用新的配置项去启动新的work进程

当停止work进程时，会像master进程发送信号，然后父进程新启一个work进程

命令行中的许多命令其实就是向master发送信号而已