Nginx 的原理解析 && worker 配置及相关问题 -细节狂魔

前言

本专栏文章的内容均来自于B站up主“尚硅谷”的教程视频。
博主的博客，你可以理解为是博主在做笔记，方便复习。
希望也可以帮到你们。

---

 

Nginx 的最基本的执行过程（master & worker）

通常我们对于 master 这个单词的理解是：雇主（管理员），表示 ““主” 的意思。
而 worker 这单词的理解：工作这，劳动者。
 
我们可以这么去理解 Nginx ：
   Nginx 在 linux 系统中，其实是有两个进程（master，worker）的。
我们可以通过查询nginx进程来验证我们的结论.
输入指令：ps -ef | grep nginx

我们可以发现：当 Nginx 运行的时候，nginx 有两个进程在运行，其就是 master 和 worker 进程。
 
通俗一点来说：
master 就相当于老板（雇主），worker 就是员工。
雇主当然不会亲力亲为，要不然雇员工干什么？
master 起着 分配工作 的作用。
worker 起着 落实（完成）工作 的作用。
总结：master 给 worker 分配工作。
另外，worker是可以有多个的！只是现在是一个。

---

 

worker 是如何进行工作的

当 client（客户端）发送请求 到 Nginx 时，请求会先进入 master 中，由 master 来分配这个请求给其中的一个 worker 来执行。
但是，我们知道：
  通常一个老板是有多个员工的。
那么这些 “员工” 又是这样拿到 “工作” 的呢？
这里运用的是 “争抢” 的机制。
简单来说：
  当 master 收到请求之后，会通知 worker 们，有活了！
worker们就会过来抢，谁抢到谁来做。
 
这里提醒一下：Nginx 本身是不支持 Java 进行直接操作的！
所以，需要借助 Tomcat 来操作Java项目，完成请求任务。
因此，worker 也是需要配置请求转发 / 反向代理 的。

---

 

一个 master 和 多个 woker 有哪些好处

1、可以使用 nginx 热部署

指令：nginx -s reload
作用：
  与 IDEA 的热部署（热加载）的作用是一样的，当代码发生改变时，会自动重启项目。
也就是说，当使用热部署指令启动 nginx 服务之后，如果 nginx 配置发生改变，它 “ 自动重启 ” 服务。
 
注意！随之问题的到来：nginx 的服务能停吗？
答案是不能！如果用户此时在进行对数据库操作的时，就会出现问题！
 
此时，多个 worker 的作用就体现出来了！
拿到任务的 worker 继续做着自己的事；
没拿到任务的 worker ，就会去加载（更新） nginx 最新配置；
当下一个请求的到来的时候，worker 们此时已是最新状态了。
当然，前面做任务的worker 执行完成之后，也会去加载 nginx 最新的配置文件。
 
这样，我们就可以在不影响用户使用的情况下，完成对 nginx 配置文件的更新！

---

 

2、节省资源 && worker 进程之间互不影响 && nginx 服务不会中断

首先，对于每个 worker 进程 来说，独立的进程，不需要加锁，所以省掉了锁带来的开销，同时在编程 以及问题查找 时，也会方便很多。
其次，采用独立的进程，可以让互相之间不会影响。
一个进程退出后，其它进程还在工作，服务不会中断，master 进程则很快启动新的 worker进程，当然 worker 进程的异常退出，肯定是程序有bug了。
异常退出，会导致当前 worker 上的所有请求失败，不过不会影响到所有请求，所以降低了风险。

---

 

woker 设置多少才最好

Nginx 同 Redis 类似都采用了 io 多路复用机制，每个 worker 都是一个独立的进程，但每个进程里只有一个主线程，通过异步非阻塞的方式处理请求，即使千上万个请求也不再话下。每个 worker 的线程可以把一个 cpu 的性能发挥到极致，所以 worker 数 和 服务器的cpu数 相等是最为适宜的，设少了会浪费 cpu，设多了会造成 cpu 频繁切换上下文带来的损耗。

worker 数 和 服务器的cpu数 相等：
如果你的cpu是四核，那就设置4个 worker 最合适。

 
注意！如果你是 Windows 系统 安装 Nginx / Redis，它们就 没有 io 多路复用机制 了。
虽然功能能够正常使用，但是 无法将 cpu 的性能发挥到极致！
所以，一般都是安装在 Linux 系统上。

---

 

设置 worker 数量

1、打开 Nginx 配置文件：
 
2、定位到 events 块
【在 nginx.conf 文件中，找到 events 块，它位于 http 块之前】
 
3、设置 worker_processes 数量
multi_accept on ：
  是一个事件配置指令，用于告诉 Nginx 工作进程在每次接受到一个新连接后，是否应该再次尝试接受更多的连接。
  默认情况下，当一个工作进程接受到一个连接后，它将停止接受新连接，直到当前连接被处理完毕。启用 multi_accept on 后，工作进程会在每次接受到一个新连接后立即再次尝试接受其他连接，从而允许单个工作进程处理更多的并发连接。
  这可以显著提高 Nginx 的并发处理能力，因为它允许单个工作进程最大化地利用其处理能力，而不需要等待当前连接处理完毕后再去接受新的连接
 
epoll ：
  是 Linux 平台上使用的一种高级事件通知机制，它是 select 和 poll 机制的增强版，主要用于处理高并发网络应用。
  在 Nginx 中，use epoll 指令用于指定 Nginx 使用 epoll 作为其事件驱动模型。epoll 提供了比传统 select 和 poll 更好的性能，尤其是在处理大量并发连接时。

  epoll 的工作原理是它将文件描述符（如套接字）分组到多个“兴趣列表”中，并根据文件描述符的状态来通知 Nginx 何时执行读取或写入操作。这种机制减少了系统调用的次数，从而提高了性能.

---

 

worker 的连接数 worker_connection

这个值表示每个 worker 进程所能建立连接的最大值.
所以，一个 nginx 能建立的最大连接数 ：
worker_connections * worker_processes
【worker最大连接值   x   worker进程数量】
 
对于 http 请求 本地资源来说，能够支持的 最大并发数量是：worker_connections * worker_processes
 
 
如果是 支持 http1,1 的浏览器每次访问 要占两个连接，所以普通的静态访问最大并发数 是：worker_connections * worker_processes / 2
 
而如果是 HTTP 作为反向代理来说，最大并发量应该是：
worker_connections * worker_processes / 4
因为作为 反向代理服务器， 每个并发建立 会与 客户端的连接和后端服务器的连接，会占用两个连接。

---

 

延伸问题

1、当发送一个请求，占用了 worker 几个连接数？

答：不是 2个，就是 4 个。
 
这么去理解： worker 接受请求，返回响应，这里就去了2个。
当该请求需要访问数据库，也就是借助 Tomcat 去完成请求，这里给 Tomcat 发送请求，接收 Tomcat 响应，就又会占用 2 个连接。

总结：当访问静态 资源时（存储静态资源服务器上）时，占 2个 连接。
访问动态资源，借助 Tomcat（访问数据库 / 操作 Java 代码 ）时，占用 4 个连接。

---

 

2、1个 master，4个 worker的情况下，1个 nginx 能建立的最大连接数（最大并发量）是多少？

假设 一个worker的最大连接数是 1024 的情况下。
worker 的最大连接 数： 1024 * 4 = 4096
worker 的最大并发 数： 1024 * 4 / 2 = 2048   1024 * 4 / 4 = 1024