Nginx学习笔记二：Nginx架构基础(一)

目录

1、Nginx的请求处理流程

2、Nginx的进程结构

3、信号管理

4、reload重载配置文件的真相

5、热升级流程

6、优雅地关闭worker进程

7、网络收发与Nginx事件间的对应关系

8、Nginx事件驱动模型

9、epoll的优劣及原理

---

1、Nginx的请求处理流程

• 大致有三种流量传输到Nginx中：web，email及TCP流量，进入Nginx以后，Nginx中有三个状态机，分别是处理TCP/UDP的传输层状态机，处理应用层的HTTP状态机和处理邮件的MAIL状态机。
• 为什么叫状态机呢？因为Nginx核心是用非阻塞的事件驱动处理引擎，也就是epoll，一旦我们使用这种异步处理引擎，通常都是需要用状态机来把请求正确地识别和处理，基于这种状态机，我们在解析请求需要访问静态资源的时候，就找到左下方的静态资源，如果去做反向代理时，对反向代理的内容就可以做磁盘缓存。
• 但是我们在处理静态资源时，会有一个问题，当内存不足以完全缓存所有文件/信息时，像AIO这样的调用会退化成阻塞的调用，所以需要使用线程池处理磁盘阻塞调用。
• 对每一个处理完成的请求，会记录Access访问日志和Error错误日志。
• 更多的时候Nginx是作为负载均衡或反向代理来使用，我们可以把请求通过协议机传输到服务器里，也可以通过例如应用层的一些协议FastCGI等代理到相应的应用服务器。

2、Nginx的进程结构

1. 单进程结构：适合开发调试使用
2. 多进程结构：默认配置

• 父进程叫MASTER PROCESS，有很多子进程，分为两类，一类是worker进程，一类是cache相关的进程。
• 为什么采用多进程结构而不是多线程结构？因为Nginx要保持高可用，高可靠性。因为线程之间共享同一个地址空间，当某个第三方模块引发了地址空间导致的断错误时，在地址越界出现时，会导致整个Nginx进程挂掉。 而当我们采用多进程往往就不会出现这样的问题。
• Ngxin在做进程设计时，同样遵循了实现高可用，高可靠性的目的。比如在master进程中，通常第三方模块不会在这里加入自己的功能代码。虽然Nginx在设计时允许第三方模块在master进程中添加自己独有的自定义的方法，但通常没有第三方模块会这么做。
• master进程设计目的是用来做worker进程的管理，所有的worker进程处理真正的请求。master进程负责监控每个worker进程是不是在正常工作，是否需要重新载入配置文件，是否需要做热部署。
• 缓存实际上要在多个worker进程间共享的，而且缓存不单被worker进程使用，也要被Cache Manager和Cache Loader进程所使用。
• Cache Manager和Cache Loader也是为反向代理时后端发来的动态请求做缓存所使用的，Cache Manager做缓存管理，Cache Loader做缓存载入。实际上每个请求处理时使用到缓存还是由worker进程来进行的，这些进程间的通讯都是使用共享内存来解决的。
• 为什么worker进程要很多？Cache Manager和Cache Loader各有一个进程，而master因为是父进程，因此只有一个。Nginx采用了事件驱动模型以后，它希望每个worker进程从头到尾占有一个CPU，所以往往我们不止要把worker进程的数量配置与服务器上的CPU核数一致以外，还需把每一个worker进程与某一颗CPU核绑定在一起，这样更好地使用CPU和CPU缓存，减少缓存失效命中率。

3、信号管理

Nginx支持以下几种信号选项：

• TERM，INT：快速关闭
• QUIT ：优雅的关闭进程，即等请求结束后再关闭
• HUP ：平滑重启，重新加载配置文件
• USR1 ：重新读取日志文件，在切割日志时用途较大
• USR2 ：平滑升级可执行程序  ，nginx升级时候用
• WINCH ：从容关闭工作进程

Nginx信号控制语法：

• kill -信号选项  nginx的主进程号

4、reload重载配置文件的真相

reload流程

1. 向master进程发送HUP信号（reload命令）
2. master进程检验配置语法是否正确
3. master进程打开新的监听端口
4. master进程用新配置启动新的worker子进程
5. master进程向老worker子进程发送QUIT信号
6. 老worker进程关闭监听句柄，处理完当前连接后结束进程

5、热升级流程

1. 将旧Nginx文件换成新Nginx文件（注意备份旧Nginx文件，命令cp -f ）
2. 向master进程发送 USR2 信号
3. master进程会修改pid文件名，加后缀.oldbin（为了管理方便，保存master进程pid，为了让新的master进程使用pid.bin文件，将老的pid文件改名）
4. master进程用新Nginx文件启动新master进程（新，旧版本的Nginx实例会同时运行，共同处理请求）
5. 向老master进程发送 WINCH 信号，老的master进程会优雅地关闭老worker，master仍存在。
6. 回滚：向老master发送 HUP ，向新master发送 QUIT

6、优雅地关闭worker进程

worker进程：优雅的关闭是指worker进程可以识别出当前的连接没有正在处理请求，再进行关闭

对于有些请求，Nginx做不到优雅关闭。在代理websocket协议时，在某层不解析帧，做tcp层反向代理时无法识别一个请求需要经历多少报文才算结束，但对于http请求是可以做到的，因此优雅关闭主要针对http请求。

1. 设置定时器 worker_shutdown_timeout：加标志位
2. 关闭监听句柄：不再处理新的连接
3. 关闭空闲连接
4. 在循环中等待全部连接关闭：可能消耗时间过长，超过timeout，导致强制关闭部分连接，即优雅的关闭只完成了一半
5. 退出进程

---

7、网络收发与Nginx事件间的对应关系

事件收集分发消费器。Nginx会定义每类事件消费者，每种事件都会建立消费者。

8、Nginx事件驱动模型

• 当Ngxin刚刚启动时，等待新的事件进来，这一步往往对应着epoll中的epoll_wait方法（阻塞方法），这时Nginx还是处于睡眠状态。
• 当操作系统收到一个建立TCP连接的握手报文，并且处理完握手流程后，操作系统会通知epoll_wait阻塞方法，告诉它可以往下走，同时唤醒Nginx的woker进程。
• KERNEL是操作系统内核，操作系统会将准备好的事件放在事件队列中。从事件队列中我们可以一个一个地获取到需要处理的事件。
• 处理事件过程中可能会生成新的事件，加入事件队列中，等待下次处理。
• 当所有事件都处理完后，会返回到 Waitfor Events On Connections。

有时候我们使用一些第三方模块，第三方模块可能会做大量的CPU运算，这样的计算任务会导致处理一个事件的时间过长，从下图可以看到，会导致后续队列中大量事件长时间得不到处理，从而引发恶性循环，也就是超时时间到了，大量的cpu和Nginx的任务都消耗在处理连接不正常地断开，所以往往Nginx不能容忍有些第三方模块长时间的消耗大量cpu进行计算任务。因此应该分段使用CPU，而不是一次使用大量CPU。

9、epoll的优劣及原理

在上述循环中，Nginx怎样能够快速地从操作系统的KERNEL中获取到等待处理的事件，这个简单的步骤其实经历了很长时间的解决。现在Nginx主要在使用 epoll 这个网络事件收集器模型。

• 从上图可以看到随着句柄数的增加，也就是并发连接数的增加，Select、Poll所消耗的时间是急剧上升的。而 epoll 基本上是与句柄数增加无关的，它的性能好很多，非常适合做高并发连接处理。

       epoll为什么适合做高并发连接处理？比如说现在Nginx现在要处理一百万个连接，从事件分发图可以看出，我们每两次做等待接收新的事件中，时间可能会非常的短，在短短几百毫秒中，所能收到的报文数量是非常有限的，而这些有限的事件所对应的连接也是有限的，也就是每次处理事件时，虽然总共有一百万个并发连接，但可能只接收到几百个活跃连接，只需要处理几百个活跃的请求。而 select/poll 的实现是有问题的，因为每一次去取操作系统的事件时，都需要把一百万个连接统统的扔给操作系统，让它依次判断哪些连接上面有事件进来了，可以看到操作系统做了大量的无用功，扫描了大量不活跃的连接。

• epoll 维护了一个数据结构 eventpoll ，通过两个数据结构将两件事分开，也就是Nginx每次取事件连接的时候，只需要去遍历一个链表，这个链表里仅有活跃的连接，这样的效率和速度就很高。
• 添加、修改、删除的时间复杂度都是N(logN)
• 获取句柄只是去遍历 rdllink ，将其从内核态读取到用户态，所耗时间很少