nginx源码分析--master和worker进程模型
一、Nginx整体架构
正常执行中的码书nginx会有多个进程,其中最基本的码书是master process(主进程)和worker process(工作进程),还可能包括cache相关进程。码书
二、码书核心进程模型
启动nginx的码书h5邀请函源码免费下载主进程将充当监控进程,主进程通过fork()产生的码书子进程则充当工作进程。
Nginx也支持单进程模型,码书此时主进程即是码书工作进程,不包含监控进程。码书
核心进程模型框图如下:
master进程
监控进程作为整个进程组与用户的码书交互接口,负责监护进程,码书不处理网络事件,码书不负责业务执行,码书仅通过管理worker进程实现重启服务、码书平滑升级、网络锁机源码更换日志文件、配置文件实时生效等功能。
master进程通过sigsuspend()函数调用大部分时间处于挂起状态,直到接收到信号。
master进程通过检查7个标志位来决定ngx_master_process_cycle方法的运行:
sig_atomic_t ngx_reap;
sig_atomic_t ngx_terminate;
sig_atomic_t ngx_quit;
sig_atomic_t ngx_reconfigure;
sig_atomic_t ngx_reopen;
sig_atomic_t ngx_change_binary;
sig_atomic_t ngx_noaccept;
进程中接收到的信号对Nginx框架的意义:
还有一个标志位:ngx_restart,仅在master工作流程中作为标志位使用,与信号无关。
核心代码(ngx_process_cycle.c):
ngx_start_worker_processes函数:
worker进程
worker进程主要负责具体任务逻辑,主要关注与客户端或后端真实服务器之间的数据可读/可写等I/O交互事件,因此工作进程的阻塞点在select()、epoll_wait()等I/O多路复用函数调用处,等待数据可读/写事件。也可能被新收到的进程信号中断。
master进程如何通知worker进程进行某些工作?采用的是信号。
当收到信号时,皮皮搞笑app源码信号处理函数ngx_signal_handler()会执行。
对于worker进程的工作方法ngx_worker_process_cycle,它主要关注4个全局标志位:
sig_atomic_t ngx_terminate;//强制关闭进程
sig_atomic_t ngx_quit;//优雅地关闭进程(有唯一一段代码会设置它,就是接受到QUIT信号。ngx_quit只有在首次设置为1时,才会将ngx_exiting置为1)
ngx_uint_t ngx_exiting;//退出进程标志位
sig_atomic_t ngx_reopen;//重新打开所有文件
其中ngx_terminate、ngx_quit、ngx_reopen都将由ngx_signal_handler根据接收到的信号来设置。ngx_exiting标志位仅由ngx_worker_cycle方法在退出时作为标志位使用。
核心代码(ngx_process_cycle.c):
Nginx源码导读:[3]Ngnix头文件处理
这节主要讲一下nginx , 对头文件的包含 ,怎么处理多次包含的 ,其实也可以是小的C语言知识点
在nginx中有很多头文件 ngx_core.h ngx_errno.h 等等, 并且他们很多相互包含了 ,大家可能会想那不是残雪教程网源码有重复定义了很多数据结构吗 ?
回答是当然不是,还记得上一节中的头文件吗 ,在这我们也拿过来 , ngx_config.h : #ifndef _NGX_CONFIG_H_INCLUDED_ #define _NGX_CONFIG_H_INCLUDED_ #include "ngx_linux_config.h" typedef intptr_t ngx_int_t; typedef uintptr_t ngx_uint_t; typedef intptr_t ngx_flag_t; #endif 发现了吗 , nginx开头都有 #ifndef XXXXX ,nginx就是用这个条件宏来去重的 ,如果第一次就会#define_NGX_CONFIG_H_INCLUDED_ ,以后某个文件在include这个头文件 ,#ifndef _NGX_CONFIG_H_INCLUDED_ 这个判断就是false了,直接就都#endif了
#ifndef这个语法是预处理执行的 ,类似于方面里面的if语句 ,但是预处理不同的是 ,处理完了 ,不满足条件的 ,编译后是不存的 , 而if语句是会怎么的 ,是在运行时做的条件判断
Nginx源码分析 - HTTP模块篇 - TCP连接建立过程
Nginx源码分析 - HTTP模块篇 - TCP连接建立过程
在上一章节中,我们已经了解了HTTP模块的英雄联盟 战绩源码初始化过程。本章节将深入剖析监听套接字的初始化函数以及Nginx连接的全程流程。 首先, ngx_http_optimize_servers 是关键函数,它负责Nginx服务监听套接字的优化配置。这个函数在Nginx启动时,会初始化并优化服务器的侦听策略。 紧接着, ngx_http_init_listening 和 ngx_http_add_listening 函数共同作用,创建和设置监听套接字(listening),为后续的网络连接做好准备。 理解了Event模块的进程初始化后,结合 ngx_http_optimize_servers 的工作,我们可以构建出Nginx连接的完整流程图。这个流程涉及服务器的监听,客户端的请求,以及两者之间的TCP连接建立。 让我们通过下面的流程概述来直观地理解:服务器通过 ngx_http_optimize_servers 函数设置监听套接字,等待客户端连接请求。
当客户端发起连接时,Nginx通过 ngx_http_add_listening 创建新的TCP连接。
通过Event模块的事件驱动,Nginx接收并处理客户端的HTTP请求,开始HTTP会话。
Nginx源码分析 - 主流程篇 - Nginx的启动流程
文章内容包含对Nginx源码的基础理解,以及对其主流程的深入分析。首先介绍了Nginx使用的各种基础数据结构,如pool、buf、array、list等,通过理解这些结构能更加深入地了解Nginx源码。
接下来,文章着重分析了Nginx的启动流程,主要实现函数在./src/core/nginx.c文件中的main()函数。文章展示了main()函数启动过程,并详细解释了几个关键步骤。
第一步,是通过ngx_get_options方法解析外部参数,比如命令行参数 ./nginx -s stop|start|restart。
第二步,初始化全局变量,其中init_cycle在内存池上创建一个默认大小为的全局变量,这一过程在ngx_init_cycle函数中完成,详细的全局变量初始化步骤会在后续的文章中展开。
第三步,通过ngx_save_argv和ngx_process_options保存头部的全局变量定义。
接着,使用ngx_preinit_modules方法对所有模块进行初始化,并给它们打上标号,这一过程在ngx_module.c文件中进行。
再一步,通过ngx_create_pidfile创建PID文件,文件管理在ngx_cycle.c文件中实现。
此外,文章还提到了Nginx中涉及的其他重要模块,指出这些模块的详细解析会在后续的文章中呈现。
总结,文章以实际代码为例,介绍了Nginx启动的全流程,并对关键步骤进行了解释,为读者深入了解Nginx源码奠定了基础。
Nginx源码分析 - 主流程篇 - 全局变量cycle初始化
Nginx的全局初始化过程围绕全局变量“cycle”展开,位于/src/core/cycle.c文件,其数据结构为“ngx_cycle_t”。了解Nginx源码前应掌握cycle全局变量初始化流程。 cycle初始化分为以下步骤: 创建内存池 用于后续分配的所有内存。 拷贝配置文件路径前缀 如“/usr/local/nginx”,存储在cycle->conf_prefix中。 复制Nginx路径前缀 存储于cycle->prefix。 复制配置文件信息 包含文件路径,如“/nginx/conf/nginx.conf”。 复制配置参数信息 初始化路径信息 初始化打开的文件句柄 初始化shared_memory链表 新旧链表比较,保留相同内存,释放不同。 遍历并打开文件列表(如日志、配置文件) 创建并初始化共享内存 比较新旧共享内存,保留或创建。 处理listening数组并开始监听 处理socket监听。 关闭或删除old_cycle资源 关键点在于内存池的创建、配置文件解析、文件句柄与共享内存的初始化、socket监听与资源关闭,整个流程确保Nginx核心组件的初始化完成。nginx ç¨ä»ä¹è¯è¨åç
1ãNginxæ¯Cè¯è¨åç2ãä¸è½½nginx-1..0.tar.gzæ¥çæºä»£ç
3ãcoreæ件
2024-11-30 11:00
2024-11-30 10:31
2024-11-30 10:29
2024-11-30 10:09
2024-11-30 09:26