Nginx 设计架构概览

叁歲伎倆 2022-11-17 14:39 341阅读 0赞

## Nginx服务器架构 ##

Nginx服务器启动后，产生一个**主进程**（master process），主进程执行一系列工作后产生一个或者多个**工作进程**（worker process）。  
![在这里插入图片描述][20210417122821428.png]  
主进程主要进行Nginx配置文件解析、数据结构初始化、模块配置和注册、信号处理、网络监听生成、工作进程生成和管理等工作；工作进程主要进行进程初始化、模块调用和请求处理等工作，是Nginx服务器提供服务的主体。在客户端请求动态站点的过程中，Nginx服务器还涉及和后端服务器的通信。Nginx服务器将接收到的Web请求通过代理转发到后端服务器，由后端服务器进行数据处理和页面组织，然后将结果返回。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70]  
另外，Nginx服务器为了提高对请求的响应效率，进一步降低网络压力，采用了缓存机制，将历史应答数据缓存到本地。在每次Nginx服务器启动后的一段时间内，会**启动专门的进程对本地缓存的内容重建索引**，保证对缓冲文件的快速访问。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 1]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 2]  
master 负责管理 worker 进程，worker 进程负责处理网络事件。整个框架被设计为一种依赖事件驱动、异步、非阻塞的模式。  
如此设计的优点：  
1.可以充分利用多核机器，增强并发处理能力。  
2.多 worker 间可以实现负载均衡。  
3.Master 监控并统一管理 worker 行为。在 worker 异常后，可以主动拉起 worker 进程，从而提升了系统的可靠性。并且由 Master 进程控制服务运行中的程序升级、配置项修改等操作，从而增强了整体的动态可扩展与热更的能力。

## Nginx服务器的进程 ##

### 主进程 ###

主进程是Nginx服务器启动时运行的主要进程。它的主要功能是与外界通信和对内部其他进程进行管理，具体来说有以下几点：读取Nginx配置文件并验证其有效性和正确性；建立、绑定和关闭Socket；按照配置生成、管理和结束工作进程；接收外界指令，比如重启、升级及退出服务器等指令；不中断服务，实现平滑重启,应用新配置；不中断服务，实现平滑升级，升级失败进行回滚处理；开启日志文件，获取文件描述符；编译和处理Perl脚本。  
master 进程的主逻辑在ngx\_master\_process\_cycle，核心关注源码：

ngx_master_process_cycle(ngx_cycle_t *cycle)
    { 
        ...
        ngx_start_worker_processes(cycle, ccf->worker_processes,
                                            NGX_PROCESS_RESPAWN);
        ...
    
    
        for ( ;; ) { 
            if (delay) { ...}
    
            ngx_log_debug0(NGX_LOG_DEBUG_EVENT, cycle->log, 0, "sigsuspend");
    
            sigsuspend(&set);
    
            ngx_time_update();
    
            ngx_log_debug1(NGX_LOG_DEBUG_EVENT, cycle->log, 0,
                                 "wake up, sigio %i", sigio);
    
            if (ngx_reap) { 
                ngx_reap = 0;
                ngx_log_debug0(NGX_LOG_DEBUG_EVENT, cycle->log, 0, "reap children");
                live = ngx_reap_children(cycle);
            }
    
            if (!live && (ngx_terminate || ngx_quit)) { ...}
    
            if (ngx_terminate) { ...}
    
            if (ngx_quit) { ...}
    
            if (ngx_reconfigure) { ...}
    
            if (ngx_restart) { ...}
    
            if (ngx_reopen) { ...}
    
            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 信号量。  
3.监控 worker 进程的运行状态。比如ngx\_reap代表CHILD信号，表示有子进程意外结束，这时需要监控所有子进程的运行状态，主要由ngx\_reap\_children完成。  
4.当 woker 进程退出后（异常情况下），会自动重新启动新的 woker 进程。主要也是在ngx\_reap\_children

热重载-配置热更  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 3]  
nginx 热更配置时，可以保持运行中平滑更新配置，具体流程如下：  
1.更新 nginx.conf 配置文件，向 master 发送 SIGHUP 信号或执行 nginx -s reload  
2.master 进程使用新配置，启动新的 worker 进程  
3.使用旧配置的 worker 进程，不再接受新的连接请求，并在完成已存在的连接后退出

热升级-程序热更  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 4]  
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。

### 工作进程 ###

由主进程生成，生成数量可以通过Nginx配置文件指定，正常情况下生存与主进程的整个生命周期。该进程的主要工作有以下几项：接收客户端请求；将请求依次送入各个功能模块进行过滤处理；IO调用，获取响应数据；与后端服务器通信，接收后端服务器处理结果；数据缓存，访问缓存索引、查询和调用缓存数据；发送请求结果，响应客户端请求；接收主程序指令，比如重启、升级和退出等指令。  
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方法实现，其中事件主要包括：网络事件、定时器事件。

worker 进程在处理网络事件时，依靠 epoll 模型，来管理并发连接，实现了事件驱动、异步、非阻塞等特性。如下图所示：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 5]  
通常海量并发连接过程中，每一时刻（相对较短的一段时间），往往只需要处理一小部分有事件的连接即活跃连接。基于以上现象，epoll 通过将连接管理与活跃连接管理进行分离，实现了高效、稳定的网络 IO 处理能力。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 6]  
其中，epoll 利用红黑树高效的增删查效率来管理连接，利用一个双向链表来维护活跃连接。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 7]

#### 惊群 ####

由于 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锁，只有获得锁的进程，才可以处理连接事件。

#### 负载均衡 ####

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的值就是一个负数，其值为连接总数的 7/8。当该进程的连接数达到总连接数的 7/8 时，该进程就不会再处理新的连接了，同时每次调用’ngx\_process\_events\_and\_timers’时，将ngx\_accept\_disabled减 1，直到其值低于阈值时，才试图重新处理新的连接。因此，nginx 各 worker 子进程间的负载均衡仅在某个 worker 进程处理的连接数达到它最大处理总数的 7/8 时才会触发，其负载均衡并不是在任意条件都满足。如下图所示：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 8]  
其中’pid’为 1211 的进程为 master 进程，其余为 worker 进程

### 缓存索引重建及管理进程（Cache Loader & Cache Manager） ###

Cache模块主要由缓存索引重建Cache Loader和缓存索引管理Cache Manager两类进程完成工作。缓存索引重建进程是在Nginx服务启动一段时间之后（默认是1分钟）由主进程生成，在缓存元数据重建完成后就自动退出；缓存索引管理进程一般存在于主进程的整个生命周期，负责对缓存索引进行管理。  
缓存索引重建进程完成的主要工作是，根据本地磁盘上的缓存文件在内存中建立索引元数据库。该进程启动后，对本地磁盘上存放缓存文件的目录结构进行扫描，检查内存中已有的缓存元数据是否正确，并更新索引元数据库。  
缓存索引管理进程主要负责在索引元数据更新完成后，对元数据是否过期做出判断。

## 进程交互 ##

主进程与工作进程之间的交互和工作进程之间的交互都依赖于管道机制，交互的准备工作都是工作进程生成时完成的。

### Master-Worker交互 ###

工作进程是由主进程生成的（使用了fork函数），Nginx服务器启动后，主进程根据配置文件决定生成的工作进程的数量，然后建立一张全局的工作进程表用于存放当前未退出的所有工作进程。  
在主进程生成工作进程后，**将新生成的工作进程加入到工作进程表中，并建立一个单向管道并将其传递给该工作进程**。该管道与普通的管道不用，它是由主进程指向工作进程的单向管道，包含了主进程向工作进程发出的指令、工作进程ID、工作进程在工作进程表中的索引和必要的文件描述符等信息。  
主进程与外界通过信号机制进行通信，当接收到需要处理的信号时，它通过管道向相关的工作进程发送正确的指令。**每个工作进程都有能力捕获管道中可读事件，当管道中有可读事件时，工作进程从管道读取并解析指令**，然后采取相应的措施。

### Worker-Worker交互 ###

worker-worker交互在实现原理上和master-worker交互基本是一样的。只要工作进程之间能够得到彼此的信息，建立管道，即可通信。由于工作进程之间是相互隔离的，因此一个进程要想知道另一个进程的信息，只能通过主进程来设置了。  
为了达到工作进程之间交互的目的，**主进程在生成工作进程后，在工作进程表中进行遍历，将该新进程的ID以及针对该进程建立的管道句柄传递给工作进程表中的其他进程**，为工作进程之间的交互做准备。每个工作进程捕获管道中可读事件，根据指令采取响应的措施。  
当工作进程W1需要向W2发送指令时，首先在主进程给它的其他工作进程信息中找到W2的进程ID，然后将正确的指令写入指向W2的通道。工作进程W2捕获到管道中的事件后，解析 指令并采取相应的措施。

## Run Loops事件处理循环模型 ##

Run Loops指的是**进程内部用来不停调配工作，对事件进行循环处理的一种模型**。它属于进程或线程的基础架构部分。该模型对事件的处理不是自动的，需要在设计代码过程中，*在适当的时候启动Run-Loop机制对输入的事件作出相应*。  
该模型是一个集合，集合中的每一个元素称为一个Run Loop。每个Run Loop可运行在不同的模式下，其中可以包含它所监听的输入事件源、定时器以及在事件发生时需要通知的Run Loop监听器（Run Loop Observers）。为了监听特定的事件，可以在Run Loops中添加相应的RuN Loop监听器。当被监听的事件发生时，Run Loop会产生一个消息，被Run Loop监听器捕获，从而执行预定的动作。

为什么不采用多线程模型管理连接？  
1.无状态服务，无需共享进程内存  
2.采用独立的进程，可以让互相之间不会影响。一个进程异常崩溃，其他进程的服务不会中断，提升了架构的可靠性。  
3.进程之间不共享资源，不需要加锁，所以省掉了锁带来的开销。  
为什么不采用多线程处理逻辑业务？  
1.进程数已经等于核心数，再新建线程处理任务，只会抢占现有进程，增加切换代价。  
2.作为接入层，基本上都是数据转发业务，网络 IO 任务的等待耗时部分，已经被处理为非阻塞/全异步/事件驱动模式，在没有更多 CPU 的情况下，再利用多线程处理，意义不大。并且如果进程中有阻塞的处理逻辑，应该由各个业务进行解决，比如 openResty 中利用了 Lua 协程，对阻塞业务进行了优化。

[20210417122821428.png]: /images/20221022/6a6b2561b4964d069b124d913fcd3e41.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70]: /images/20221022/0d0e7dc355604c31aa8c97c22f8bdc7d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 1]: /images/20221022/f77d75dae1234a40bf96f737029f1cab.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 2]: /images/20221022/077d3f3cd67b4fe6a42ff42afabe091a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 3]: /images/20221022/a625669e995345578e1a84d3c9fdc2c5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 4]: /images/20221022/999aa3e811984434bf25713304ebdcdf.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 5]: /images/20221022/795b6dae28834f9ba487024c68cf25bf.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 6]: /images/20221022/051a26c57f6a4afbb8d5d078776d1d1d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 7]: /images/20221022/8b47401b86874684a32094116b40f181.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzbWFydGtpbGxlcg_size_16_color_FFFFFF_t_70 8]: /images/20221022/b17e3a592f594d9dbd988d4f6a3af012.png