- 浏览: 1407241 次
- 性别:
- 来自: 火星
-
文章分类
最新评论
-
aidd:
内核处理time_wait状态详解 -
ahtest:
赞一下~~
一个简单的ruby Metaprogram的例子 -
itiProCareer:
简直胡说八道,误人子弟啊。。。。谁告诉你 Ruby 1.9 ...
ruby中的类变量与类实例变量 -
dear531:
还得补充一句,惊群了之后,数据打印显示,只有一个子线程继续接受 ...
linux已经不存在惊群现象 -
dear531:
我用select试验了,用的ubuntu12.10,内核3.5 ...
linux已经不存在惊群现象
nginx采用的也是大部分http服务器的做法,就是master,worker模型,一个master进程管理站个或者多个worker进程,基本的事件处理都是放在woker中,master负责一些全局初始化,以及对worker的管理。
在nginx中master和worker的通信是通过socketpair来实现的,每次fork完一个子进程之后,将这个子进程的socketpaire句柄传递给前面已经存在的子进程,这样子进程之间也就可以通信了。
nginx中fork子进程是在ngx_spawn_process中进行的:
第一个参数是全局的配置,第二个参数是子进程需要执行的函数,第三个参数是proc的参数。第四个类型。
这个函数主要的任务就是:
1 有一个ngx_processes全局数组,包含了所有的存货的子进程,这里会fork出来的子进程放入到相应的位置。并设置这个进程的相关属性。
2 创建socketpair,并设置相关属性。
3 在子进程中执行传递进来的函数。
在看详细代码之前,我们先来看几个主要的数据结构:
首先是进程结构,这个结构体表示了一个进程。包含了它的id状态,channel等等。
下面我们来看详细的代码。
先来看第一部分:
接下来新建一对socketpair句柄,然后初始化相关属性。
接下来就是fork子进程,并设置进程相关参数。
这里有个问题,那就是后面fork的子进程如何来让前面已经fork的子进程得到自己的进程相关信息呢。在nginx中是每次新的子进程fork完毕后,然后父进程此时将这个子进程id,以及流管道的句柄channel[0]传递给前面的子进程。这样子进程之间也可以通信了。
先来看相关的数据结构:
接下来来看代码:
而在子进程中是如何处理的呢,子进程的管道可读事件捕捉函数是ngx_channel_handler(ngx_event_t *ev),在这个函数中,会读取mseeage,然后解析,并根据不同的命令做不同的处理,来看它的代码片断:
接下来详细的来看worker和master如何进行交互,以及master如何同外部进行交互(比如热代码替换,reconfig这些操作)。
在nginx中,worker和master的交互,我们前面已经提过了,就是通过流管道以及信号,而master与外部的交互是通过信号来进行的。
在看master得主循环之前,我们先来看信号处理和函数,在nginx中,父子进程的信号处理函数是相同的,只不过有一个变量在master和worker中赋值不同,以此来区分。
在信号处理中,通过设置相应的标志变量,从而在主循环中,判断这些变量,从而做相应的操作。
先来看master的主循环,处理其实很简单,就是在循环过程中判断相应的条件,然后进入相应的处理。这里的相关标志位基本都是在上面的信号处理函数中赋值的。:
然后来看worker的主循环,worker的比较简单。逻辑和master的很相似:
在nginx中master和worker的通信是通过socketpair来实现的,每次fork完一个子进程之后,将这个子进程的socketpaire句柄传递给前面已经存在的子进程,这样子进程之间也就可以通信了。
nginx中fork子进程是在ngx_spawn_process中进行的:
第一个参数是全局的配置,第二个参数是子进程需要执行的函数,第三个参数是proc的参数。第四个类型。
ngx_pid_t ngx_spawn_process(ngx_cycle_t *cycle, ngx_spawn_proc_pt proc, void *data, char *name, ngx_int_t respawn)
这个函数主要的任务就是:
1 有一个ngx_processes全局数组,包含了所有的存货的子进程,这里会fork出来的子进程放入到相应的位置。并设置这个进程的相关属性。
2 创建socketpair,并设置相关属性。
3 在子进程中执行传递进来的函数。
在看详细代码之前,我们先来看几个主要的数据结构:
首先是进程结构,这个结构体表示了一个进程。包含了它的id状态,channel等等。
typedef struct { ///进程id ngx_pid_t pid; ///进程的退出状态(主要在waitpid中进行处理). int status; ///进程channel(也就是通过socketpair创建的两个句柄) ngx_socket_t channel[2]; ///进程的执行函数(也就是每次spawn,子进程所要执行的那个函数). ngx_spawn_proc_pt proc; void *data; char *name; ///进程的几个状态。 unsigned respawn:1; unsigned just_respawn:1; unsigned detached:1; unsigned exiting:1; unsigned exited:1; } ngx_process_t;
下面我们来看详细的代码。
先来看第一部分:
//全局的进程表,保存了存活的子进程。 ngx_process_t ngx_processes[NGX_MAX_PROCESSES]; ................................... u_long on; ngx_pid_t pid; ///表示将要fork的子进程在ngx_processes中的位置, ngx_int_t s; ///首先,如果传递进来的类型大于0,则就是已经确定这个进程已经退出,我们就可以直接确定slot。 if (respawn >= 0) { s = respawn; } else { ///遍历ngx_processess,从而找到空闲的slot,从而等会fork完毕后,将子进程信息放入全局进程信息表的相应的slot。 for (s = 0; s < ngx_last_process; s++) { if (ngx_processes[s].pid == -1) { break; } } ///到达最大进程限制报错。 if (s == NGX_MAX_PROCESSES) { ngx_log_error(NGX_LOG_ALERT, cycle->log, 0, "no more than %d processes can be spawned", NGX_MAX_PROCESSES); return NGX_INVALID_PID; } }
接下来新建一对socketpair句柄,然后初始化相关属性。
///如果类型为NGX_PROCESS_DETACHED,则说明是热代码替换(热代码替换也是通过这个函数进行处理的),因此不需要新建socketpair。 if (respawn != NGX_PROCESS_DETACHED) { /* Solaris 9 still has no AF_LOCAL */ ///建立socketpair if (socketpair(AF_UNIX, SOCK_STREAM, 0, ngx_processes[s].channel) == -1) { ngx_log_error(NGX_LOG_ALERT, cycle->log, ngx_errno, "socketpair() failed while spawning \"%s\"", name); return NGX_INVALID_PID; } 。。。。。。。。。。。。。。。。。。。。。。。。。。。。 ///设置非阻塞模式 if (ngx_nonblocking(ngx_processes[s].channel[0]) == -1) { ........................................................ } if (ngx_nonblocking(ngx_processes[s].channel[1]) == -1) { ........................................ } ///打开异步模式 on = 1; if (ioctl(ngx_processes[s].channel[0], FIOASYNC, &on) == -1) { ................................................. } ///设置异步io的所有者 if (fcntl(ngx_processes[s].channel[0], F_SETOWN, ngx_pid) == -1) { .............................................. } ///当exec后关闭句柄。 if (fcntl(ngx_processes[s].channel[0], F_SETFD, FD_CLOEXEC) == -1) {................................................ } if (fcntl(ngx_processes[s].channel[1], F_SETFD, FD_CLOEXEC) == -1) { 。。。。。。。。。。。。。。。。。。。。。。。。。。 } ///设置当前的子进程的句柄 ngx_channel = ngx_processes[s].channel[1]; } else { ngx_processes[s].channel[0] = -1; ngx_processes[s].channel[1] = -1; }
接下来就是fork子进程,并设置进程相关参数。
///设置进程在进程表中的slot。 ngx_process_slot = s; pid = fork(); switch (pid) { case -1: ngx_log_error(NGX_LOG_ALERT, cycle->log, ngx_errno, "fork() failed while spawning \"%s\"", name); ngx_close_channel(ngx_processes[s].channel, cycle->log); return NGX_INVALID_PID; case 0 ///子进程,因此执行传递进来的子进程的函数 ngx_pid = ngx_getpid(); proc(cycle, data); break; default: break; } ngx_log_error(NGX_LOG_NOTICE, cycle->log, 0, "start %s %P", name, pid); ngx_processes[s].pid = pid; ngx_processes[s].exited = 0; ///如果大于0,则说明我们确定了重启的子进程,因此下面的初始化就用已死的子进程的就够了。 if (respawn >= 0) { return pid; } ///开始初始化进程结构。 ngx_processes[s].proc = proc; ngx_processes[s].data = data; ngx_processes[s].name = name; ngx_processes[s].exiting = 0; ///设置相关状态。 switch (respawn) { case NGX_PROCESS_RESPAWN: ngx_processes[s].respawn = 1; ngx_processes[s].just_respawn = 0; ngx_processes[s].detached = 0; break; case NGX_PROCESS_JUST_RESPAWN: ngx_processes[s].respawn = 1; ngx_processes[s].just_respawn = 1; ngx_processes[s].detached = 0; break; case NGX_PROCESS_DETACHED: ngx_processes[s].respawn = 0; ngx_processes[s].just_respawn = 0; ngx_processes[s].detached = 1; break; } if (s == ngx_last_process) { ngx_last_process++; } return pid;
这里有个问题,那就是后面fork的子进程如何来让前面已经fork的子进程得到自己的进程相关信息呢。在nginx中是每次新的子进程fork完毕后,然后父进程此时将这个子进程id,以及流管道的句柄channel[0]传递给前面的子进程。这样子进程之间也可以通信了。
先来看相关的数据结构:
///封装了父子进程之间传递的信息。 typedef struct { ///对端将要做得命令。 ngx_uint_t command; ///当前的子进程id ngx_pid_t pid; ///在全局进程表中的位置 ngx_int_t slot; ///传递的fd ngx_fd_t fd; } ngx_channel_t;
接下来来看代码:
static void ngx_start_worker_processes(ngx_cycle_t *cycle, ngx_int_t n, ngx_int_t type) { ngx_int_t i, s; ngx_channel_t ch; .................................... ///传递给其他子进程的命令 ch.command = NGX_CMD_OPEN_CHANNEL; ///这里n,就是从配置文件中读取的,需要几个子进程。 for (i = 0; i < n; i++) { cpu_affinity = ngx_get_cpu_affinity(i); ///这个函数刚才介绍过了。就是fork子进程。 ngx_spawn_process(cycle, ngx_worker_process_cycle, NULL, "worker process", type); ///初始化channel,ngx_process_slot这个我们在上面的spawn函数中已经赋值完毕,就是当前子进程的位置。 ch.pid = ngx_processes[ngx_process_slot].pid; ch.slot = ngx_process_slot; ch.fd = ngx_processes[ngx_process_slot].channel[0]; ///遍历整个进程表 for (s = 0; s < ngx_last_process; s++) { ///遇到非存活的进程就跳过。 if (s == ngx_process_slot || ngx_processes[s].pid == -1 || ngx_processes[s].channel[0] == -1) { continue; } ngx_log_debug6(NGX_LOG_DEBUG_CORE, cycle->log, 0, "pass channel s:%d pid:%P fd:%d to s:%i pid:%P fd:%d", ch.slot, ch.pid, ch.fd, s, ngx_processes[s].pid, ngx_processes[s].channel[0]); /* TODO: NGX_AGAIN */ ///然后传递这个channel给其他子进程(主要是传递句柄)。 ngx_write_channel(ngx_processes[s].channel[0], &ch, sizeof(ngx_channel_t), cycle->log); } } }
而在子进程中是如何处理的呢,子进程的管道可读事件捕捉函数是ngx_channel_handler(ngx_event_t *ev),在这个函数中,会读取mseeage,然后解析,并根据不同的命令做不同的处理,来看它的代码片断:
///这里ch为读取的channel。 switch (ch.command) { case NGX_CMD_QUIT: ngx_quit = 1; break; case NGX_CMD_TERMINATE: ngx_terminate = 1; break; case NGX_CMD_REOPEN: ngx_reopen = 1; break; case NGX_CMD_OPEN_CHANNEL: ///可以看到操作很简单,就是对ngx_processes全局进程表进行赋值。 ngx_processes[ch.slot].pid = ch.pid; ngx_processes[ch.slot].channel[0] = ch.fd; break; case NGX_CMD_CLOSE_CHANNEL: ..................................................... if (close(ngx_processes[ch.slot].channel[0]) == -1) { ngx_log_error(NGX_LOG_ALERT, ev->log, ngx_errno, "close() channel failed"); } ngx_processes[ch.slot].channel[0] = -1; break; }
接下来详细的来看worker和master如何进行交互,以及master如何同外部进行交互(比如热代码替换,reconfig这些操作)。
在nginx中,worker和master的交互,我们前面已经提过了,就是通过流管道以及信号,而master与外部的交互是通过信号来进行的。
在看master得主循环之前,我们先来看信号处理和函数,在nginx中,父子进程的信号处理函数是相同的,只不过有一个变量在master和worker中赋值不同,以此来区分。
在信号处理中,通过设置相应的标志变量,从而在主循环中,判断这些变量,从而做相应的操作。
///定义的信号值。 #define NGX_SHUTDOWN_SIGNAL QUIT #define NGX_TERMINATE_SIGNAL TERM #define NGX_NOACCEPT_SIGNAL WINCH #define NGX_RECONFIGURE_SIGNAL HUP #if (NGX_LINUXTHREADS) #define NGX_REOPEN_SIGNAL INFO #define NGX_CHANGEBIN_SIGNAL XCPU #else #define NGX_REOPEN_SIGNAL USR1 #define NGX_CHANGEBIN_SIGNAL USR2 #endif void ngx_signal_handler(int signo) { char *action; ngx_int_t ignore; ngx_err_t err; ngx_signal_t *sig; ignore = 0; err = ngx_errno; ///首先得到当前的信号值 for (sig = signals; sig->signo != 0; sig++) { if (sig->signo == signo) { break; } } ngx_time_update(0, 0); action = ""; ///这里ngx_process在master和worker中赋值不同。 switch (ngx_process) { ///master中。 case NGX_PROCESS_MASTER: case NGX_PROCESS_SINGLE: switch (signo) { case ngx_signal_value(NGX_SHUTDOWN_SIGNAL): ///如果接受到quit信号,则准备退出进程。 ngx_quit = 1; action = ", shutting down"; break; case ngx_signal_value(NGX_TERMINATE_SIGNAL): case SIGINT: ///sigint信号,则 ngx_terminate = 1; action = ", exiting"; break; case ngx_signal_value(NGX_NOACCEPT_SIGNAL): ///winch信号,停止接受accept。 ngx_noaccept = 1; action = ", stop accepting connections"; break; case ngx_signal_value(NGX_RECONFIGURE_SIGNAL): ///sighup信号用来reconfig ngx_reconfigure = 1; action = ", reconfiguring"; break; case ngx_signal_value(NGX_REOPEN_SIGNAL): ///用户信号,用来reopen ngx_reopen = 1; action = ", reopening logs"; break; ///热代码替换. case ngx_signal_value(NGX_CHANGEBIN_SIGNAL): if (getppid() > 1 || ngx_new_binary > 0) { /* * Ignore the signal in the new binary if its parent is * not the init process, i.e. the old binary's process * is still running. Or ignore the signal in the old binary's * process if the new binary's process is already running. */ ///上面注释很详细,我就不解释了。。 action = ", ignoring"; ignore = 1; break; } ///正常情况下,需要热代码替换。设置标志位 ngx_change_binary = 1; action = ", changing binary"; break; case SIGALRM: break; case SIGIO: ngx_sigio = 1; break; case SIGCHLD: ///子进程已退出,设置标记。 ngx_reap = 1; break; } break; ///worker的信号处理。worker的比较简单。 case NGX_PROCESS_WORKER: switch (signo) { case ngx_signal_value(NGX_NOACCEPT_SIGNAL): ngx_debug_quit = 1; case ngx_signal_value(NGX_SHUTDOWN_SIGNAL): ngx_quit = 1; action = ", shutting down"; break; case ngx_signal_value(NGX_TERMINATE_SIGNAL): case SIGINT: ngx_terminate = 1; action = ", exiting"; break; case ngx_signal_value(NGX_REOPEN_SIGNAL): ngx_reopen = 1; action = ", reopening logs"; break; ............................................... } break; } ................................................ ///最终如果信号是sigchld,我们收割僵尸进程(用waitpid)。 if (signo == SIGCHLD) { ngx_process_get_status(); } ngx_set_errno(err); }
先来看master的主循环,处理其实很简单,就是在循环过程中判断相应的条件,然后进入相应的处理。这里的相关标志位基本都是在上面的信号处理函数中赋值的。:
for ( ;; ) { ///delay用来等待子进程退出的时间,由于我们接受到SIGINT信号后,我们需要先发送信号给子进程,而子进程的退出需要一定的时间,超时时如果子进程已退出,我们父进程就直接退出,否则发送sigkill信号给子进程(强制退出),然后再退出。 if (delay) { delay *= 2; .............................................. itv.it_interval.tv_sec = 0; itv.it_interval.tv_usec = 0; itv.it_value.tv_sec = delay / 1000; itv.it_value.tv_usec = (delay % 1000 ) * 1000; ///设置定时器。 if (setitimer(ITIMER_REAL, &itv, NULL) == -1) { ngx_log_error(NGX_LOG_ALERT, cycle->log, ngx_errno, "setitimer() failed"); } } ///延时,等待定时器。 sigsuspend(&set); ngx_time_update(0, 0); ngx_log_debug0(NGX_LOG_DEBUG_EVENT, cycle->log, 0, "wake up"); ///ngx_reap为1,说明有子进程已经退出。 if (ngx_reap) { ngx_reap = 0; ngx_log_debug0(NGX_LOG_DEBUG_EVENT, cycle->log, 0, "reap children"); ///这个里面处理退出的子进程(有的worker异常退出,这时我们就需要重启这个worker ),如果所有子进程都退出则会返回0. live = ngx_reap_children(cycle); } ///如果没有存活的子进程,并且收到了ngx_terminate或者ngx_quit信号,则master退出。 if (!live && (ngx_terminate || ngx_quit)) { ngx_master_process_exit(cycle); } ///收到了sigint信号。 if (ngx_terminate) { ///设置延时。 if (delay == 0) { delay = 50; } if (delay > 1000) { ///如果超时,则强制杀死worker ngx_signal_worker_processes(cycle, SIGKILL); } else { ///负责发送sigint给worker,让它退出。 ngx_signal_worker_processes(cycle, ngx_signal_value(NGX_TERMINATE_SIGNAL)); } continue; } ///收到quit信号。 if (ngx_quit) { ///发送给worker quit信号 ngx_signal_worker_processes(cycle, ngx_signal_value(NGX_SHUTDOWN_SIGNAL)); ls = cycle->listening.elts; for (n = 0; n < cycle->listening.nelts; n++) { if (ngx_close_socket(ls[n].fd) == -1) { ngx_log_error(NGX_LOG_EMERG, cycle->log, ngx_socket_errno, ngx_close_socket_n " %V failed", &ls[n].addr_text); } } cycle->listening.nelts = 0; continue; } ///收到需要reconfig的信号 if (ngx_reconfigure) { ngx_reconfigure = 0; ///判断是否热代码替换后的新的代码还在运行中(也就是还没退出当前的master)。如果还在运行中,则不需要重新初始化config。 if (ngx_new_binary) { ngx_start_worker_processes(cycle, ccf->worker_processes, NGX_PROCESS_RESPAWN); ngx_start_cache_manager_process(cycle, NGX_PROCESS_RESPAWN); ngx_noaccepting = 0; continue; } ngx_log_error(NGX_LOG_NOTICE, cycle->log, 0, "reconfiguring"); ///重新初始化config,并重新启动新的worker cycle = ngx_init_cycle(cycle); if (cycle == NULL) { cycle = (ngx_cycle_t *) ngx_cycle; continue; } ngx_cycle = cycle; ccf = (ngx_core_conf_t *) ngx_get_conf(cycle->conf_ctx, ngx_core_module); ngx_start_worker_processes(cycle, ccf->worker_processes, NGX_PROCESS_JUST_RESPAWN); ngx_start_cache_manager_process(cycle, NGX_PROCESS_JUST_RESPAWN); live = 1; ngx_signal_worker_processes(cycle, ngx_signal_value(NGX_SHUTDOWN_SIGNAL)); } ///这个标志没弄懂有什么意义。代码里面是当热代码替换后,如果ngx_noacceptig被设置了,则设置这个标志位(难道意思是热代码替换前要先停止当前的accept连接?) if (ngx_restart) { ngx_restart = 0; ngx_start_worker_processes(cycle, ccf->worker_processes, NGX_PROCESS_RESPAWN); ngx_start_cache_manager_process(cycle, NGX_PROCESS_RESPAWN); live = 1; } ///重新打开log if (ngx_reopen) { ngx_reopen = 0; ngx_log_error(NGX_LOG_NOTICE, cycle->log, 0, "reopening logs"); ngx_reopen_files(cycle, ccf->user); ngx_signal_worker_processes(cycle, ngx_signal_value(NGX_REOPEN_SIGNAL)); } ///热代码替换 if (ngx_change_binary) { ngx_change_binary = 0; ngx_log_error(NGX_LOG_NOTICE, cycle->log, 0, "changing binary"); ///进行热代码替换,这里是调用execve来执行新的代码。 ngx_new_binary = ngx_exec_new_binary(cycle, ngx_argv); } ///接受到停止accept连接,其实也就是worker退出(有区别的是,这里master不需要退出).。 if (ngx_noaccept) { ngx_noaccept = 0; ngx_noaccepting = 1; ///给worker发送信号。 ngx_signal_worker_processes(cycle, ngx_signal_value(NGX_SHUTDOWN_SIGNAL)); } } }
然后来看worker的主循环,worker的比较简单。逻辑和master的很相似:
for ( ;; ) { ///ngx_exiting是当收到master的quit命令后,设置为1,然后等待其他资源退出。 if (ngx_exiting) { c = cycle->connections; ............................................. ///定时器超时则退出worker if (ngx_event_timer_rbtree.root == ngx_event_timer_rbtree.sentinel) { ngx_log_error(NGX_LOG_NOTICE, cycle->log, 0, "exiting"); ngx_worker_process_exit(cycle); } } ngx_log_debug0(NGX_LOG_DEBUG_EVENT, cycle->log, 0, "worker cycle"); ngx_process_events_and_timers(cycle); ///收到shutdown命令则worker直接退出 if (ngx_terminate) { ngx_log_error(NGX_LOG_NOTICE, cycle->log, 0, "exiting"); ngx_worker_process_exit(cycle); } ///收到quit命令 if (ngx_quit) { ngx_quit = 0; ngx_log_error(NGX_LOG_NOTICE, cycle->log, 0, "gracefully shutting down"); ngx_setproctitle("worker process is shutting down"); if (!ngx_exiting) { ///关闭socket,然后设置退出标志。 ngx_close_listening_sockets(cycle); ngx_exiting = 1; } } ///收到master重新打开log的命令。 if (ngx_reopen) { ngx_reopen = 0; ngx_log_error(NGX_LOG_NOTICE, cycle->log, 0, "reopening logs"); ngx_reopen_files(cycle, -1); } }
发表评论
-
nginx中sub_request的处理
2010-06-30 18:17 11887首先来看subrequest的处理。 什么是subreque ... -
nginx中handler的处理(二)
2010-05-30 18:33 12480这次我们来看各个phase ... -
nginx中handler的处理(一)
2010-05-20 01:09 13213nginx中的处理一个http的请求分为了8个phase,分别 ... -
nginx中的output chain的处理(二)
2010-05-09 13:45 10242接着上次的分析继续, ... -
nginx中锁的设计以及惊群的处理
2010-05-03 02:13 19460nginx中使用的锁是自己来实现的,这里锁的实现分为两种情况, ... -
nginx中的output chain的处理(一)
2010-04-24 00:59 7206这里我们详细来看ngx_linux_sendfile_chai ... -
nginx的filter的处理
2010-04-13 00:38 11803随笔拿一个nginx的filter模块来看,gzip模块,来看 ... -
nginx中request请求的解析
2010-04-04 01:15 12041ngx_http_init_request 中初始化event ... -
linux已经不存在惊群现象
2010-01-02 22:10 16057惊群也就是指多个进程 ... -
nginx的内存管理
2009-12-10 01:20 12827先来看内存池的实现,nginx的内存池实现的非常简单。 这里 ...
相关推荐
Nginx内存模型的核心思想是在启动之初预分配一大块内存,而不是在运行过程中不断地申请和释放小块内存。这种做法能够有效提高内存分配的效率,并减少由于频繁的内存申请和释放所导致的内存碎片问题。 - **优点**: ...
Nginx作为一款广泛应用的Web服务器,其独特的多进程模型设计深受赞誉。本文将深入探讨从Nginx视角出发的服务器多进程模型设计,帮助读者理解其背后的原理与优势。 首先,我们要了解Nginx的基本结构。Nginx采用主...
NGINX的进程模型可以用以下图表表示: .. image:: http://tengine.taobao.org/book/_images/chapter-2-1.PNG :alt: nginx 进程模型 :align: center 操作NGINX 在操作NGINX时,我们可以通过向master进程发送信号来...
1. Nginx进程模型:Nginx采用多进程模型,由主进程和工作进程组成。主进程主要负责读取配置文件、管理子进程等。工作进程则负责处理实际的网络请求。在多核处理器系统上,工作进程可利用多个CPU核心,处理更多并发...
Nginx 使用多进程模型,主进程与工作进程通过共享内存进行通信。工作进程通常以非特权用户运行,以提高安全性。主进程负责配置管理和维护工作进程,而工作进程处理网络连接和请求。 ### 配置文件与日志管理 Nginx ...
下面我们将深入探讨Nginx进程模型的工作原理。 ##### 1.1 监控进程 (Master Process) - **职责**:监控进程负责管理整个进程组,并作为外部通信的接口。具体包括: - 接收来自客户端的信号(例如重启、平滑升级等...
#### 二、Nginx进程模型详解 **2.1 Master Process的角色与职责** Master Process主要承担以下职责: - 接收来自外部的信号,并根据信号类型执行相应的操作。 - 管理Worker Processes,包括创建、销毁Worker ...
1. **事件驱动架构**:Nginx 使用异步、非阻塞的事件模型,能够同时处理大量的并发连接,这使得它在处理高流量网站时表现出色。 2. **反向代理**:Nginx 可以作为反向代理服务器,将客户端请求转发到后端应用服务器...
进程标识符是 Nginx 服务器记录进程信息的重要组件,我们可以通过 `pid` 指令来设置进程标识符的存放路径,例如 `pid /usr/local/nginx/logs/nginx.pid;`,这将设置进程标识符的存放路径为 /usr/local/nginx/logs/...
- 高并发:Nginx采用事件驱动模型,能够处理大量并发连接,特别适合高流量网站。 - 轻量级:Nginx内存占用少,资源消耗低,提高了服务器效率。 - 反向代理:作为反向代理服务器,Nginx可以将来自客户端的请求转发...
Nginx 采用主进程(master process)+ 工作进程(worker processes)的模型运行。主进程负责读取和解析配置文件,然后创建并管理多个工作进程。工作进程则负责实际的网络I/O和请求处理。 ### 六、Nginx 运维 在...
Nginx 采用事件驱动的异步非阻塞模型,通过多工作进程的方式,有效利用系统资源,实现高效的服务响应。主进程负责管理子进程,而工作进程则处理实际的网络请求。 ### 2. Nginx 的配置文件 Nginx 的配置主要通过 `...
其核心优势在于其优秀的并发处理能力,轻量级的进程模型以及高效的内存管理,这使得Nginx在高流量网站中表现出色。 Nginx的配置文件是其强大功能的关键。在提供的文件列表中,我们看到有三个与配置相关的文件:`...
首先,书中介绍了Nginx的基本架构和工作原理,包括事件模型、多进程和线程模型、非阻塞I/O等关键概念。Nginx采用异步非阻塞模型处理请求,这使得它在高并发环境下表现优秀,能够有效地利用系统资源。 接着,详细...
Nginx以其高效的事件驱动模型和非阻塞I/O机制,在资源消耗上具有显著优势。 **Nginx-RTMP模块** Nginx-RTMP是Nginx的一个扩展模块,由Adobe Systems开发,用于支持Real-Time Messaging Protocol (RTMP)。RTMP是一...
这个过程涉及到Nginx的多进程模型,包括master进程和worker进程。升级过程中,先替换master进程,然后在不影响现有连接的情况下替换worker进程。 1. **理解升级原理**:Nginx主进程负责管理配置和子进程,worker...
然后,分别深入分析了Nginx的进程模型、数据结构、配置指令、主要功能模块、I/O事件处理、变量机制、客户端请求过程、Filter模块实例、负载均衡策略以及Handler模块等。附录部分提供了Nginx的编译模块、运行配置等...
首先,Nginx是一个高性能的Web服务器和反向代理服务器,它以其轻量级的进程模型、高并发处理能力和出色的稳定性而闻名。在内网环境中,Nginx通常用于提供内部服务,例如静态文件服务、API代理转发等,同时也能作为...
在0.1版代码中,可以研究NGINX如何解析配置文件,理解指令解析、变量处理等过程,这对于定制和扩展NGINX配置有很大帮助。 通过对NGINX 0.1版源代码的分析,我们可以深入了解其基本架构和设计原则。尽管随着版本...
7. **进程模型**:Nginx使用主进程(Master)和工作进程(Worker)的模型。主进程负责读取和解析配置文件,而工作进程处理实际的网络IO和请求。 8. **错误处理**:当遇到错误时,Nginx会生成错误日志,例如404表示...