共计 1401 个字符，预计需要花费 4 分钟才能阅读完成。
本文章转自：乐字节
文章次要解说：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 为什么不采纳多线程解决逻辑业务？
感激大家的认同与反对，小编会继续转发《乐字节》优质文章
