nginx工作原理:

首先nginx,采用的是多线程&多路io复用模型,使用I/O多路复用技术的nginx,成就了”并发驱动”的服务器.

nginx的框架模型:

进程组件角色:

master进程: 监视工作进程的状态,当工作进程死掉后重启一个新的,处理信号和通知工作进程.

work进程: 处理客户端请求,从主进程处获得信号,根据指示去做对应的事情,

cache Loader进程: 加载缓存索引文件信息,人后退出,

cacheManger进程: 管理磁盘的缓存大小,超过预定值大小后最少使用数据将被删除.

nnginx多进程的工作模式: nginx在启动后,会有一个master进程和多个worker进程,.master进程主要用来管理worker进程,包含:接受来自外界的信号,向各worker进程发送信号,监控worker进程的运行状态,当worker进程退出后,会自动重新启动新的worker进程,,而基本的网络事件,则是放在worker进程中来处理,多个worker进程之间的是对等的,他们同等竞争来自客户端的请求.各个进程之间是相互独立的,可能会加锁.一个请求只可能在一个worker进程上进程处理,不能同时处理其他进程.

注意:

worker进程数,一般会设置成cpu内核数,因为更多的worker数,只会导致进程相互竞争cpu的资源,从而带来不必要的上下文切换,使用多进程模式,不仅能提高并发效率,而在进程之间相互独立,一个worker进程挂掉,不会影响其他worker进程工作.同时,master会接受到信号,对该任务重新分配一个worker进程.

Nginx的请求处理流程:

多种流量进入nginx后,nginx的三种状态机开始工作:

调用非阻塞事件驱动模型epoll: 传输层状态机, http状态机,mail状态机,

在nginx解析出请求后,会动用线程池处理调用将静态资源方向代理,错误日志等信息分别导向不同的出口,如: fastcgi会导向php处理,html会导向nginx处理.并将处理的请求记录日志到本地或远程服务器

基于这样的事件处理状态机:我们在解析出请求需要访问静态资源的时候,我们看到轴走左下方箭头,就会去访问对应的静态资源,.,如果我们做反向代理的时候,那么对方向代理的内容,我们可以做磁盘缓存,缓存到磁盘上,也是在这条路上.但当我们在处理静态资源的时候,会有一个问题,就是当整个内存已经不足以完全缓存所有文件和信息,的时候,

那么就会像send File这样调用或者AIO会退化称为阻塞的磁盘调用,所以在这里需要有一个线程池来处理,对于每一个处理完成的请求,我们会进入access日志或者error日志,

那么这里也是进入了磁盘中的，当然我们可以通过 syslog 协议把它进入到远程的机器上，那么更多的时候我们的 Nginx 是作为负载均衡或者反向代理来使用的，就是我们可以把请求通过协议级（HTTP，Mail 及 stream（TCP））传输到后面的服务器，也可以通过例如应用层的一些协议（FastCGI、uWSGI、SCGI、memcached）代理到相应的应用服务器。以上就是 Nginx 的请求处理流程。

Nginx接受请求连接事件模块流程

os内核: 建立三次握手, 当用户发来一个 SYN 报文时,系统内核会返回一个SYN+ACK确认给客户端,当用户再次发送ACK来的时候,此时就已经建立了三次握手.

完成三次握手后,os会根据系统的负载均衡算法来选中一个worker线程,它会返回一个建立连接的epoll_wait的句柄,拿到了epoll_wait的链接句柄后找到它监听的端口80或者443等端口,拿到端口后,开始调用accept方法来分配512个字节的连接内存池,,分配完成后内存池后,http模块会从事件中接入请求的处理过程,

http模块启动后,ngx_http_init_connection设置并启用一个回调方法:前面的epoll_ctl,并为这个方法添加一个定时器, (client_header_timeout:60s)(这个在nginx,conf文件中有),然后继续读取事件添加到这个epoll事件中,并开始计算时间60s.如果超时就会返回信息.

在请求完成后,nginx会将请求数据读取到用户态中,并在链接内存池中为他分配一个读的缓冲区, clent_header_bufer_size:1k [之前分配的是512字节,这里是可扩展的分配的1k,这里的1k 是强制占用,无论你现有字节会不会超过1k 都会强行占用1k]

接收请求HTTP模块:收到url后,开始分配内存池,并做上下文解析,分析每一个head和http协议,所以这里需要分配一个默认请求内存池, request_poll_size:4k;

此时,状态机会解析请求行: 如:方法名,url,协议, 解析请求行的过程中可能会发现有的URL更大,已经超过了我们之前设置的1k了此时我们会调用一个大内存: large_client_header_buffers: 4 8k; (最多32k).

当状态机解析完了请求行后,表示URL用于指向请求行, (这里也是nginx强大的原因,他可以指定请求行,不用遍历).,标识结束后,开始接受head,并开始解析,head同时复用large_client_header_buffers: 4 8k;的的内存,接受完成的header后,标识header,并且移除定时器,(clent_header_timeout:60s) 移除定时器后,就开始11个阶段的http请求处理.

惊群现象:

master进程首先通过socket()(套接字)来创建一个sock文件描述符用来监听,然后fok生成一个子进程,(workers进程),子进程将继承父进程的sockfd(socket 文件描述符),之后子进程accept()后将创建已连接描述符,然后通过已连接描述符与客户端通信.

那么，由于所有子进程都继承了父进程的 sockfd，那么当连接进来时，所有子进程都将收到通知并“争着”与它建立连接，这就叫“惊群现象”。大量的进程被激活又挂起，只有一个进程可以accept() 到这个连接，这当然会消耗系统资源。

Nginx对惊群现象的处理：
　　Nginx 提供了一个 accept_mutex 这个东西，这是一个加在accept上的一把互斥锁。即每个 worker 进程在执行 accept 之前都需要先获取锁，获取不到就放弃执行 accept()。有了这把锁之后，同一时刻，就只会有一个进程去 accpet()，这样就不会有惊群问题了。accept_mutex 是一个可控选项，我们可以显示地关掉，默认是打开的。

　这样做带来的好处：

1、节省锁带来的开销。每个 worker 进程都是独立的进程，不共享资源，不需要加锁。同时在编程以及问题查上时，也会方便很多。

2、独立进程，减少风险。采用独立的进程，可以让互相之间不会影响，一个进程退出后，其它进程还在工作，服务不会中断，master 进程则很快重新启动新的 worker 进程。当然，worker 进程的也能发生意外退出。