Nginx架构初识

1.Nginx请求处理流程

Nginx运行在企业内网的最外层，是边缘节点，它处理的流量是其他应用服务器的数倍或者是几个数量级倍，
Nginx在处理问题的过程中问题会被放大，我们需要了解：
1.为什么采用master-worker这种架构模型；
2.为什么worker进程的数量要和CPU核数相匹配；
3.多个进程间共享数据方式为什么在TLS或者对一些限流限速这样的场景下不同;
...

非阻塞的事件驱动处理引擎-epoll
做反向代理的时候可以对反向代理的内容做磁盘缓存，缓存到磁盘上，但是在处理静态资源的时候会有一个问题：
当整个内存不足以完全缓存住所有的文件缓存信息的时候，sendfile的调用和AIO会退化成阻塞的磁盘调用，所以
这里我们采用了线程池技术，对于每一个完成的请求，会记录access日志和error日志.

更多的时候我们的Nginx是作为负载均衡和反向代理来使用的，我们可以把请求通过协议传输到后面的应用服务器上.

2.Nginx的进程结构

1.单进程进程结构，只用做开发调试，不适合生产环境使用；
2.多进程进程结构，实际生产使用.

使用多进程而不用多线程是因为多进程更安全.
在MASTER进程中允许第三方模块添加一些特殊化的功能代码，但是第三方一般不会这么做.
MASTER进程被设计成worker进程的管理者，所有的worker进程是处理真正的请求的，master进程
负责监控每个worker进程是不是在正常地工作，需不需要做重新载入配置文件，需不需要做热部署.
至于cache，cache是需要在多个进程中共享的，cache不仅仅要被work进程使用，还要被cache manager
和cache loader进程使用，cache manager和cache loader是为反向代理时后端发来的动态请求做
缓存使用，cache loader做缓存的载入，cache manager做缓存的管理，实际上每个请求处理时使用
到缓存还是由worker进程来进行的，这些进程间的通信是通过共享内存来解决的.

为什么worker进程要很多？
因为Nginx采用事件驱动模型以后，它希望每一个worker进程从头到尾占有一个CPU，所以我们不仅仅要将
worker进程的进程数与机器的CPU核数一样以外，还需要将每个进程与一个CPU绑定在一起，这样更好地使用
每个核上的CPU缓存，来减少缓存失效的命中率.

 

3.Nginx的进程管理

我们知道，多进程之间的通信方式有管道，匿名管道，信号，共享内存等方式，在做进程管理的时候，
则通常只使用信号.Nginx中的进程管理：

Master进程：
1.监控worker进程，当子进程退出时发送给父进程的SIGCHLD信号会方便父进程重新拉起需要启动的子进程；
2.通过接受的信号管理worker进程，信号有：
  TERM，INT（TERM立刻停止）
  QUIT（QUIT优雅停止，不要对用户发出立刻结束连接导致产生复位请求等报文）
  HUP （重载配置文件）
  USR1 (重新打开配置文件做配置文件的切割)
  USR2 (只能用kill来实现，热部署时使用)
  WINCH(只能用kill来实现，热部署时使用)

Worker进程(可以直接发送信号给worker进程，但是我们通常是不这么做的，我们希望通过master进程来
管理子进程)
接受信号：
TERM，INT
QUIT
USR1
WINCH 

Nginx命令行(启动Nginx之后会把Nginx的master进程的pid记录到Nginx安装目录的logs下面的nginx.pid
中，启动命令行的时候就会去这个文件中找到pid，然后给相应进程发送对应的信号，从而达到一定的效果，
所以调用命令行和相应的直接给主进程发送信号的效果是一样的)
reload（HUP）
reopen（USR1）
stop（TERM）
quit（QUIT）

4.进程管理的一些测试图