让我一起浅析Nginx 架构

米米素材网

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

让我一起浅析Nginx 架构

1.Nginx 基础架构

 

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

让我一起浅析Nginx 架构

master与worker

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

让我一起浅析Nginx 架构

基础架构设计

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

如此设计的优点:

  • 1.可以充分利用多核机器,增强并发处理能力。
  • 2.多 worker 间可以实现负载均衡。
  • 3.Master 监控并统一管理 worker 行为。在 worker 异常后,可以主动拉起 worker 进程,从而提升了系统的可靠性。并且由 Master 进程控制服务运行中的程序升级、配置项修改等操作,从而增强了整体的动态可扩展与热更的能力。

2.Master 进程

 

2.1 核心逻辑

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

  1. ngx_master_process_cycle(ngx_cycle_t *cycle) 
  2.     ... 
  3.     ngx_start_worker_processes(cycle, ccf->worker_processes, 
  4.                                         NGX_PROCESS_RESPAWN); 
  5.     ... 
  6.  
  7.  
  8.     for ( ;; ) { 
  9.         if (delay) {...} 
  10.  
  11.         ngx_log_debug0(NGX_LOG_DEBUG_EVENT, cycle->log, 0, "sigsuspend"); 
  12.  
  13.         sigsuspend(&set); 
  14.  
  15.         ngx_time_update(); 
  16.  
  17.         ngx_log_debug1(NGX_LOG_DEBUG_EVENT, cycle->log, 0, 
  18.                              "wake up, sigio %i", sigio); 
  19.  
  20.         if (ngx_reap) { 
  21.             ngx_reap = 0; 
  22.             ngx_log_debug0(NGX_LOG_DEBUG_EVENT, cycle->log, 0, "reap children"); 
  23.             live = ngx_reap_children(cycle); 
  24.         } 
  25.  
  26.         if (!live && (ngx_terminate || ngx_quit)) {...} 
  27.  
  28.         if (ngx_terminate) {...} 
  29.  
  30.         if (ngx_quit) {...} 
  31.  
  32.         if (ngx_reconfigure) {...} 
  33.  
  34.         if (ngx_restart) {...} 
  35.  
  36.         if (ngx_reopen) {...} 
  37.  
  38.         if (ngx_change_binary) {...} 
  39.  
  40.         if (ngx_noaccept) { 
  41.             ngx_noaccept = 0; 
  42.             ngx_noaccepting = 1; 
  43.             ngx_signal_worker_processes(cycle, 
  44.                                                   ngx_signal_value(NGX_SHUTDOWN_SIGNAL)); 
  45.         } 
  46.     } 
  47.  } 

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

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

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

3.监控 worker 进程的运行状态。比如ngx_reap代表CHILD信号,表示有子进程意外结束,这时需要监控所有子进程的运行状态,主要由ngx_reap_children完成。

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

2.2 热更

2.2.1 热重载-配置热更

让我一起浅析Nginx 架构

热重载

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

  • 1.更新 nginx.conf 配置文件,向 master 发送 SIGHUP 信号或执行 nginx -s reload
  • 2.master 进程使用新配置,启动新的 worker 进程
  • 3.使用旧配置的 worker 进程,不再接受新的连接请求,并在完成已存在的连接后退出

2.2.2 热升级-程序热更

让我一起浅析Nginx 架构

热升级

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,核心关注源码:

  1. ngx_worker_process_cycle(ngx_cycle_t *cycle, void *data) 
  2.     ngx_int_t worker = (intptr_t) data; 
  3.  
  4.     ngx_process = NGX_PROCESS_WORKER; 
  5.     ngx_worker = worker; 
  6.  
  7.     ngx_worker_process_init(cycle, worker); 
  8.  
  9.     ngx_setproctitle("worker process"); 
  10.  
  11.     for ( ;; ) { 
  12.  
  13.         if (ngx_exiting) {...} 
  14.  
  15.         ngx_log_debug0(NGX_LOG_DEBUG_EVENT, cycle->log, 0, "worker cycle"); 
  16.  
  17.         ngx_process_events_and_timers(cycle); 
  18.  
  19.         if (ngx_terminate) {...} 
  20.  
  21.         if (ngx_quit) {...} 
  22.  
  23.         if (ngx_reopen) {...} 
  24.     } 

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

3.2 事件驱动-epoll

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

让我一起浅析Nginx 架构

infographic-Inside-NGINX_nonblocking

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

让我一起浅析Nginx 架构

网络模型对比

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

让我一起浅析Nginx 架构

epoll数据结构

3.3 惊群

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

  1. void ngx_process_events_and_timers(ngx_cycle_t *cycle){ 
  2.     //这里面会对监听socket处理 
  3.     ... 
  4.  
  5.     if (ngx_accept_disabled > 0) { 
  6.             ngx_accept_disabled--; 
  7.     } else { 
  8.         //获得锁则加入wait集合, 
  9.         if (ngx_trylock_accept_mutex(cycle) == NGX_ERROR) { 
  10.             return
  11.         } 
  12.         ... 
  13.         //设置网络读写事件延迟处理标志,即在释放锁后处理 
  14.         if (ngx_accept_mutex_held) { 
  15.             flags |= NGX_POST_EVENTS; 
  16.         } 
  17.     } 
  18.     ... 
  19.     //这里面epollwait等待网络事件 
  20.     //网络连接事件,放入ngx_posted_accept_events队列 
  21.     //网络读写事件,放入ngx_posted_events队列 
  22.     (void) ngx_process_events(cycle, timer, flags); 
  23.     ... 
  24.     //先处理网络连接事件,只有获取到锁,这里才会有连接事件 
  25.     ngx_event_process_posted(cycle, &ngx_posted_accept_events); 
  26.     //释放锁,让其他进程也能够拿到 
  27.     if (ngx_accept_mutex_held) { 
  28.         ngx_shmtx_unlock(&ngx_accept_mutex); 
  29.     } 
  30.     //处理网络读写事件 
  31.     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就是负载均衡机制实现的关键阈值。

  1. ngx_int_t             ngx_accept_disabled; 
  2. ngx_accept_disabled = ngx_cycle->connection_n / 8 - ngx_cycle->free_connection_n; 

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

让我一起浅析Nginx 架构

实际工作情况

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

4.思考

 

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

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

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

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

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

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

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

原文地址:https://zhuanlan.51cto.com/art/202104/656922.htm