nginx相关知识点总结分享-tutorial php-php.cn

Nginx本身不会对PHP进行解析，终端对PHP页面的请求将会被Nginx交给FastCGI进程监听的IP地址及端口，由php-fpm作为动态解析服务器处理，最后将处理结果再返回给nginx。其实，Nginx就是一个反向代理服务器。Nginx通过反向代理功能将动态请求转向后端php-fpm，从而实现对PHP的解析支持，这就是Nginx实现PHP动态解析的原理。

Nginx不支持对外部程序的直接调用或者解析，所有的外部程序（包括PHP）必须通过FastCGI接口来调用。FastCGI接口在Linux下是socket（这个socket可以是文件socket，也可以是ip socket）。为了调用CGI程序，还需要一个FastCGI的wrapper（wrapper可以理解为用于启动另一个程序的程序），这个wrapper绑定在某个固定socket上，如端口或者文件socket。当Nginx将CGI请求发送给这个socket的时候，通过FastCGI接口，wrapper接收到请求，然后派生出一个新的线程，这个线程调用解释器或者外部程序处理脚本并读取返回数据；接着，wrapper再将返回的数据通过FastCGI接口，沿着固定的socket传递给Nginx；最后，Nginx将返回的数据发送给客户端。

经典的模型就是Nginx中所用的Master-Worker多进程异步驱动模型。

父进程创建socket，bind、listen后，通过fork创建多个子进程，每个子进程继承了父进程的socket，调用accpet开始监听等待网络连接。这个时候有多个进程同时等待网络的连接事件，当这个事件发生时，这些进程被同时唤醒，就是“惊群”。进程被唤醒，需要进行内核重新调度，这样每个进程同时去响应这一个事件，而最终只有一个进程能处理事件成功，其他的进程在处理该事件失败后重新休眠或其他。

其实在Linux2.6版本以后，内核内核已经解决了accept()函数的“惊群”问题，当内核接收到一个客户连接后，只会唤醒等待队列上的第一个进程或线程。

Nginx中使用accept_mutexmutex互斥锁解决这个问题，具体措施有使用全局互斥锁，每个子进程在epoll_wait()之前先去申请锁，申请到则继续处理，获取不到则等待，并设置了一个负载均衡的算法（当某一个子进程的任务量达到总设置量的7/8时，则不会再尝试去申请锁）来均衡各个进程的任务量。

现在我们对惊群及 Nginx 的处理总结如下：

accept 不会有惊群，epoll_wait 才会。
Nginx 的 accept_mutex,并不是解决 accept 惊群问题，而是解决 epoll_wait 惊群问题。
说Nginx 解决了 epoll_wait 惊群问题，也是不对的，它只是控制是否将监听套接字加入到epoll 中。监听套接字只在一个子进程的 epoll 中，当新的连接来到时，其他子进程当然不会惊醒了。

简单了说，就是同一时刻只允许一个nginx worker在自己的epoll中处理监听句柄。它的负载均衡也很简单，当达到最大connection的7/8时，本worker不会去试图拿accept锁，也不会去处理新连接，这样其他nginx worker进程就更有机会去处理监听句柄，建立新连接了。而且，由于timeout的设定，使得没有拿到锁的worker进程，去拿锁的频繁更高。

nginx 多进程模型真的没有锁了吗？其实还是有一个的：ngx_accept_mutex。

nginx是一个多进程程序，80端口为各worker进程共享，每当有连接到来时，势必多个worker进程都要争着去响应，这也就是所谓的惊群现象。

当内核accept一个链接时，会唤醒所有等待中的进程，但实际上只有一个进程能获取连接，其它的进程都被无效唤醒，这种无效唤醒无疑将会增加应用的开销。为此，nginx提供了一把accept锁避免九子夺嫡的悲剧。

ngx_accept_mutex的作用也就是让那些当前负载严重

的worker进程主动放弃对新到来的请求的处理，提高

应用整体的唤醒效率，进而提升应用的整体性能。

proxy_cache

upstream

fastcgi_pass

location

非标准状态码444表示关闭连接且不给客户端发响应头。

nginx -s reload 命令加载修改后的配置文件,命令下达后发生如下事件

1. Nginx的master进程检查配置文件的正确性，若是错误则返回错误信息，nginx继续采用原配置文件进行工作（因为worker未受到影响）

2. Nginx启动新的worker进程，采用新的配置文件

3. Nginx将新的请求分配新的worker进程

4. Nginx等待以前的worker进程的全部请求已经都返回后，关闭相关worker进程

5. 重复上面过程，知道全部旧的worker进程都被关闭掉

以上过程是参考nginx官方的相关文档后得出。

以 proxy_next_upstream为例，一般的配置如下：

proxy_next_upstream http_504 timeout;

这个指令有两个作用：

告诉nginx，如果发生了连接超时，上游返回504的时候，需要重试upstream
告诉nginx, http 504 ,连接超时是请求失败

总的来说， nginx对于 error, timeout, invalide_header 均默认是失败，其他的行为如果想当作失败，需要加入类似 proxy_next_upstream之类的指令里面的。其中 http_403, http_404均不认识是失败。

论两点，对 server 失败的定义和 server失败后的行为。

server 失败的定义：上面的模块失败定义主要用于说明一个请求在什么情况下是失败的；但是什么定义一个server是失败的呢？ nginx里面主要用两个参数控制 : max_fails和fail_timeout。简单的说，如果一个请求在 fail_timeout内发生了max_fails次失败，就认识改server当前是down。