Nginx架构浅析:为什么不用多线程模型管理连接与处理逻辑业务?

if (ngx_change_binary) {…}

if (ngx_noaccept) {

ngx_noaccept = 0;

ngx_noaccepting = 1;

ngx_signal_worker_processes(cycle,

ngx_signal_value(NGX_SHUTDOWN_SIGNAL));

}

}

}

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

  • 1.接受来自外界的信号。其中 master 循环中的各项标志位就对应着各种信号,如: ngx_quit代表 QUIT 信号,表示优雅地关闭整个服务。

  • 2.向各个 worker 进程发送信。比如 ngx_noaccept 代表 WINCH 信号,表示所有子进程不再接受处理新的连接,由 master 向所有的子进程发送 QUIT 信号量。

  • ngx_reap CHILD ngx_reap_children

  • 4.当 woker 进程退出后(异常情况下),会自动重新启动新的 woker 进程。主要也是在 ngx_reap_children

2.2 热更

======

2.2.1 热重载-配置热更

==============

热重载

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

  • 1.更新 nginx.conf 配置文件,向 master 发送 SIGHUP 信号或执行 nginx -s reload

  • 2.master 进程使用新配置,启动新的 worker 进程

  • 3.使用旧配置的 worker 进程,不再接受新的连接请求,并在完成已存在的连接后退出

2.2.2 热升级-程序热更

==============

热升级

nginx 热升级过程如下:

  • 1.将旧 Nginx 文件换成新 Nginx 文件(注意备份)

  • 2.向 master 进程发送 USR2 信号(平滑升级到新版本的 Nginx 程序)

  • 3.master 进程修改 pid 文件号,加后缀.oldbin

  • 4.master 进程用新 Nginx 文件启动新 master 进程,此时新老 master/worker 同时存在。

  • 5.向老 master 发送 WINCH 信号,关闭旧 worker 进程,观察新 worker 进程工作情况。若升级成功,则向老 master 进程发送 QUIT 信号,关闭老 master 进程;若升级失败,则需要回滚,向老 master 发送 HUP 信号(重读配置文件),向新 master 发送 QUIT 信号,关闭新 master 及 worker。

3.Worker 进程

===========

3.1 核心逻辑

========

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

ngx_worker_process_cycle(ngx_cycle_t *cycle, void *data)

{

ngx_int_t worker = (intptr_t) data;

ngx_process = NGX_PROCESS_WORKER;

ngx_worker = worker;

ngx_worker_process_init(cycle, worker);

ngx_setproctitle(“worker process”);

for ( ;; ) {

if (ngx_exiting) {…}

ngx_log_debug0(NGX_LOG_DEBUG_EVENT, cycle->log, 0, “worker cycle”);

ngx_process_events_and_timers(cycle);

if (ngx_terminate) {…}

if (ngx_quit) {…}

if (ngx_reopen) {…}

}

}

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

3.2 事件驱动-epoll

==============

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

infographic-Inside-NGINX_nonblocking

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

网络模型对比

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

epoll数据结构

3.3 惊群

======

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

void ngx_process_events_and_timers(ngx_cycle_t *cycle){

//这里面会对监听socket处理

if (ngx_accept_disabled > 0) {

ngx_accept_disabled–;

} else {

//获得锁则加入wai 《一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义》无偿开源 威信搜索公众号【编程进阶路】 t集合,

if (ngx_trylock_accept_mutex(cycle) == NGX_ERROR) {

return;

}

//设置网络读写事件延迟处理标志,即在释放锁后处理

if (ngx_accept_mutex_held) {

flags |= NGX_POST_EVENTS;

}

}

//这里面epollwait等待网络事件

//网络连接事件,放入ngx_posted_accept_events队列

//网络读写事件,放入ngx_posted_events队列

(void) ngx_process_events(cycle, timer, flags);

//先处理网络连接事件,只有获取到锁,这里才会有连接事件

ngx_event_process_posted(cycle, &ngx_posted_accept_events);

//释放锁,让其他进程也能够拿到

if (ngx_accept_mutex_held) {

ngx_shmtx_unlock(&ngx_accept_mutex);

}

//处理网络读写事件

ngx_event_process_posted(cycle, &ngx_posted_events);

}

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

  • 1.将连接事件与读写事件进行分离。连接事件存放为 ngx_posted_accept_events ,读写事件存放为 ngx_posted_events 。

  • 2.设置 ngx_accept_mutex 锁,只有获得锁的进程,才可以处理连接事件。

3.4 负载均衡

========

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值