写点什么

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

用户头像
极客good
关注
发布于: 刚刚
  • 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 {


//获得锁则加入 wait 集合,


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 负载均衡


========


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


ngx_int_t ngx_accept_disabled;


ngx_accept_disabled = ngx_cycle->connection_n / 8 - ngx_cycle->free_connection_n;


因此,在 nginx 启动时, ngx_accept_disabled 的值就是一个负数,其值为连接总数的


【一线大厂Java面试题解析+核心总结学习笔记+最新架构讲解视频+实战项目源码讲义】
浏览器打开:qq.cn.hn/FTf 免费领取
复制代码


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 为什么不采用多线程模型管理连接?


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


  • 1.无状态服务,无需共享进程内存

  • 2.采用独立的进程,可以让互相之间不会影响。一个进程异常崩溃,其他进程的服务不会中断,提升了架构的可靠性。

  • 3.进程之间不共享资源,不需要加锁,所以省掉了锁带来的开销。


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


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


  • 1.进程数已经等于核心数,再新建线程处理任务,只会抢占现有进程,增加切换代价。

  • 2.作为接入层,基本上都是数据转发业务,网络 IO 任务的等待耗时部分,已经被处理为非阻塞/全异步/事件驱动模式,在没有更多 CPU 的情况下,再利用多线程处理,意义不大。并且如果进程中有阻塞的处理逻辑,应该由各个业务进行解决,比如 openResty 中利用了 Lua 协程,对阻塞业务进行了优化。

用户头像

极客good

关注

还未添加个人签名 2021.03.18 加入

还未添加个人简介

评论

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