本文章转自:乐字节

文章主要讲解:Nginx 架构浅析

获取更多Java相关资料可以关注公众号《乐字节》 发送:999

1.Nginx 基础架构

nginx 启动后以 daemon 形式在后台运行,后台进程包含一个 master 进程和多个 worker 进程。如下图所示:

image-20211015152044400

nginx 是由一个 master 管理进程,多个 worker 进程处理工作的多进程模型。基础架构设计,如下图所示:

image-20211015152107251

master 负责管理 worker 进程,worker 进程负责处理网络事件。整个框架被设计为一种依赖事件驱动、异步、非阻塞的模式。

如此设计的优点:

image-20211015152127950

2.Master 进程

2.1 核心逻辑

master 进程的主逻辑在ngx_master_process_cycle,核心关注源码:

image-20211015152207245

由上述代码,可以理解,master 进程主要用来管理 worker 进程,具体包括如下 4 个主要功能:

image-20211015152220916

2.2 热更

2.2.1 热重载-配置热更

nginx 热更配置时,可以保持运行中平滑更新配置,具体流程如下:

image-20211015152242335

2.2.2 热升级-程序热更

image-20211015152256098

3.Worker 进程

3.1 核心逻辑

worker 进程的主逻辑在ngx_worker_process_cycle,核心关注源码:

image-20211015152315788

由上述代码,可以理解,worker 进程主要在处理网络事件,通过ngx_process_events_and_timers方法实现,其中事件主要包括:网络事件、定时器事件。

3.2 事件驱动-epoll

worker 进程在处理网络事件时,依靠 epoll 模型,来管理并发连接,实现了事件驱动、异步、非阻塞等特性。如下图所示:

image-20211015152329759

通常海量并发连接过程中,每一时刻(相对较短的一段时间),往往只需要处理一小部分有事件的连接即活跃连接。基于以上现象,epoll 通过将连接管理活跃连接管理进行分离,实现了高效、稳定的网络 IO 处理能力。

image-20211015152345494

其中,epoll 利用红黑树高效的增删查效率来管理连接,利用一个双向链表来维护活跃连接

image-20211015152409008

3.3 惊群

由于 worker 都是由 master 进程 fork 产生,所以 worker 都会监听相同端口。这样多个子进程在 accept 建立连接时会发生争抢,带来著名的“惊群”问题。worker 核心处理逻辑ngx_process_events_and_timers核心代码如下:

image-20211015152426908

由上述代码可知,Nginx 解决惊群的方法:

image-20211015152438541

3.4 负载均衡

worker 间的负载关键在于各自接入了多少连接,其中接入连接抢锁的前置条件是ngx_accept_disabled > 0,所以ngx_accept_disabled就是负载均衡机制实现的关键阈值。

image-20211015152450530

因此,在 nginx 启动时,ngx_accept_disabled的值就是一个负数,其值为连接总数的 7/8。当该进程的连接数达到总连接数的 7/8 时,该进程就不会再处理新的连接了,同时每次调用'ngx_process_events_and_timers'时,将ngx_accept_disabled减 1,直到其值低于阈值时,才试图重新处理新的连接。因此,nginx 各 worker 子进程间的负载均衡仅在某个 worker 进程处理的连接数达到它最大处理总数的 7/8 时才会触发,其负载均衡并不是在任意条件都满足。如下图所示:

image-20211015152502899

其中'pid'为 1211 的进程为 master 进程,其余为 worker 进程

4.思考

4.1 为什么不采用多线程模型管理连接?

image-20211015152523294

4.2 为什么不采用多线程处理逻辑业务?

image-20211015152534612

感谢大家的认同与支持,小编会持续转发《乐字节》优质文章