Nginx 架构到底有多牛

本文章转自：乐字节

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

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

1.Nginx 基础架构

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

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

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

如此设计的优点：

2.Master 进程

2.1 核心逻辑

master 进程的主逻辑在ngx_master_process_cycle，核心关注源码：

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

2.2 热更

2.2.1 热重载-配置热更

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

2.2.2 热升级-程序热更

3.Worker 进程

3.1 核心逻辑

worker 进程的主逻辑在ngx_worker_process_cycle，核心关注源码：

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

3.2 事件驱动-epoll

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

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

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

3.3 惊群

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

由上述代码可知，Nginx 解决惊群的方法：

3.4 负载均衡

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

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

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

4.思考

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

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

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