Nginx运行原理和配置详解（个人总结笔记）

话不多说，撸起键盘就是干！正所谓知其然知其所以然，个人总结了下Nginx运行原理和配置详解，便于理解和后续复盘。

先来看这一张图。

nginx启动后会有 一个master进程和多个worker进程 。master进程用来管理worker进程， 一个worker进程处理一个请求 ，一个请求，只可能在一个worker进程中处理，一个worker进程，不可能处理其它进程的请求。 worker进程的个数是可以设置的，一般我们会设置与机器cpu核数一致 ，这里面的原因与nginx的进程模型以及事件处理模型是分不开的 ，过多的worker数，只会导致进程来竞争cpu资源，从而带来不必要的上下文切换。

PHP WEB服务器目前最佳方式之一就是： Nginx + FastCGI（解决CGI并发重复fork问题） + PHP-FPM（管理PHP-CGI进程） 。nginx是怎么做到把请求抛给PHP解释来处理的呢？这个过程又是怎么实现的呢？稍后我们来看一下参数配置。

代理，反向代理，负载均衡是Nginx常用功能。

Http代理，反向代理：作为web服务器最常用的功能之一，尤其是反向代理。如果你和小马之前一样还是分不清代理和反向代理的区别，下面这个图对理解会有所帮助。

它们的区别就是，前者知道我要找的人并知道地址在哪，代理服务器按这个地址代为请求一下然后把他说的话返回给我。后者就是，我知道我要找谁问话但不知道地址在哪，我也不想管，代理服务你自己去找，只要帮我返回他要说的话就可以了。

负载均衡：其实也是 反向代理 的一种。负载均衡，热备等等其实都属于高可用范畴，Nginx提供的负载均衡策略有2种：内置策略和扩展策略。内置策略为 轮询，加权轮询，Ip hash 等等。扩展策略，就天马行空，只有你想不到的没有他做不到的啦，你可以参照所有的负载均衡算法，给他做下实现。思考一个问题，IP hash真的能解决session共享的问题么？

我们来简单看下两个 配置示例 。

这个配置将请求转发转向mysvr 定义的服务器列表。 注意proxy_pass配置。其实这块也是负载均衡的配置 。如下：

在访问网站时，由于配置了proxy_pass地址，所有请求都会先通过nginx反向代理服务器，在服务器将请求转发给目的主机时，读取upstream为 tomcatsever1的地址，读取分发策略，配置tomcat1权重为3，所以nginx会将大部分请求发送给49服务器上的tomcat1，也就是8080端口；较少部分给tomcat2来实现有条件的负载均衡，当然这个条件就是服务器1、2的硬件指数处理请求能力。

负载均衡配置 还有其他的相关参数，这是只是打个样，不赘述。

可以认为fastcgi_pass这个配置非常关键，将Nginx + FastCGI + PHP-FPM串连 。这个配置将PHP请求都交给 fastcgi_pass配置的PHP-FPM处理。 location分别通过正则过滤和转发配置决定了各个请求URL将要转发交与的处理方式 ，location /表示默认请求，location  ~\.php(.*)$ 表示PHP 脚本请求全部转发到 FastCGI处理。 使用FastCGI默认配置.。

以上配置指定了这些 静态文件要nginx自己处理 。

NGINX负载均衡可以用于很多服务负载均衡的实现，比如做Redis服务的负载均衡，配置upstream的IP列表再配置 proxy_pass 代理即可。那要实现负载均衡除了NGINX，还有哪些呢？

根据7层OSI模型可将负载均衡分为 ：

1）二层负载均衡（一般是用虚拟mac地址方式，外部对虚拟MAC地址请求，负载均衡接收后分配后端实际的MAC地址响应）；

2）三层负载均衡（一般采用虚拟IP地址方式，外部对虚拟的ip地址请求，负载均衡接收后分配后端实际的IP地址响应）；

3）四层负载均衡（在三次负载均衡的基础上，用 ip+port 接收请求，再转发到对应的机器）；

4）七层负载均衡（根据虚拟的url或是IP，主机名接收请求，再转向相应的处理服务器）。

这其中，最常见的是四层和七层负载均衡。思考一下，NGINX的负载均衡是属于哪一种？

关于负载均衡的架构

Nginx 采用的是多进程（单线程） &多路IO复用模型。使用了 I/O 多路复用技术的 Nginx，就成了”并发事件驱动“的服务器。

异步非阻塞

1、Nginx 在启动后，会有一个 master 进程和多个相互独立的 worker 进程。

2、接收来自外界的信号，向各worker进程发送信号，每个进程都有可能来处理这个连接。

3、 master 进程能监控 worker 进程的运行状态，当 worker 进程退出后(异常情况下)，会自动启动新的 worker 进程。

worker 进程数，一般会设置成机器 cpu 核数。因为更多的worker 数，只会导致进程相互竞争 cpu，从而带来不必要的上下文切换

惊群现象

主进程（master 进程）首先通过 socket() 来创建一个 sock 文件描述符用来监听，然后fork生成子进程（workers 进程），子进程将继承父进程的 sockfd（socket 文件描述符），之后子进程 accept() 后将创建已连接描述符（connected descriptor）），然后通过已连接描述符来与客户端通信。

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

Nginx对惊群现象的处理

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

主要用来管理worker进程，包含：接收来自外界的信号，向各worker进程发送信号，监控worker进程的运行状态，当worker进程退出后(异常情况下)，会自动重新启动新的worker进程。

worker进程工作流程

当一个 worker 进程在 accept() 这个连接之后，就开始读取请求，解析请求，处理请求，产生数据后，再返回给客户端，最后才断开连接，一个完整的请求

什么是IO多路复用呢？

对于 *** 作系统而言，IO多路复用就是要完成 *** 作系统IO的请求。对于IO文件的请求，当一个IO流要进行文件处理的时候，要获取一组文件的描述符，当文件描述符还没有就绪时，那么它就在等待，直到描述符一旦就绪，马上上报系统通知的机制，告诉应用程序我准备就绪，你可以来 *** 作了。这就是IO多路复用的方式。

这种机制处理起来就很高效，多路复用就是在一个线程里，交替并发的完成。复用的就是一个线程。

---