nginx worker进程循环的实现

worker进程启动后，其首先会初始化自身运行所需要的环境，然后会进入一个循环，在该循环中不断检查是否有需要执行的事件，然后处理事件。在这个过程中，worker进程也是需要与master进程交互的，更有甚者，worker进程作为一个子进程，也是可以接收命令行指令（比如kill等）以进行相应逻辑的处理的。那么worker进程是如何与master或者命令行指令进行交互的呢？本文首先会对worker进程与master进程交互方式，以及worker进程如何处理命令行指令的流程进行讲解，然后会从源码上对worker进程交互的整个工作流程进行介绍。

1. worker与master进程交互方式

这里首先需要说明的是，无论是master还是外部命令的方式，nginx都是通过标志位的方式来处理相应的指令的，也即在接收到一个指令（无论是master还是外部命令）的时候，worker会在其回调方法中设置与该指令相对应的标志位，然后在worker进程在其自身的循环中处理完事件之后会依次检查这些标志位是否为真，是则根据该标志位的作用执行相应的逻辑。

对于worker进程与master进程的交互，其是通过socket管道的方式进行的。在ngx_process.h文件中声明了一个ngx_process_t结构体，这里我们主要关注其channel属性：

1. typedef struct {
2. // 其余属性...
3.  
4. ngx_socket_t channel[2];
5. } ngx_process_t;

        这里的ngx_process_t结构体的作用是存储某个进程相关的信息的，比如pid、channel、status等。每个进程中都有一个ngx_processes数组，数组元素就是这里的ngx_process_t结构体，也就是说每个进程都会通过ngx_processes数组保存其余进程的基本信息。其声明如下：

// 存储了nginx中所有的子进程数组，每个子进程都有一个对应的ngx_process_t结构体进行标记
extern ngx_process_t ngx_processes[NGX_MAX_PROCESSES];
        这里我们就可以看出，每个进程都会一个与之对应的channel数组，这个数组的长度为2，其是与master进程进行交互的管道流。在master进程创建每一个子进程的之前，都会创建一个channel数组，该数组的创建方法为：

int socketpair(int domain, int type, int protocol, int sv[2]);
        这个方法的主要作用是创建一对匿名的已经连接的套接字，也就是说，如果在一个套接字中写入数据，那么在另一个套接字中就可以接收到写入的数据。通过这种方式，如果在父进程中往管道的一边写入数据，那么在子进程就可以在另一边接收到数据，这样就可以实现父子进程的数据通信了。

        在master进程启动完子进程之后，子进程会保有master进程中相应的数据，也包括这里的channel数组。如此，master进程就可以通过channel数组实现与子进程的通信了。

2. worker处理外部命令

        对于外部命令，其本质上是通过signals数组中定义的各个信号以及回调方法进行处理的。在master进程初始化基本环境的时候，会将signals数组中指定的信号回调方法设置到对应的信号中。由于worker进程会继承master进程的基本环境，因而worker进程在接收到这里设置的信号之后，也会调用对应的回调方法。而该回调方法的主要逻辑也仅仅只是设置相应的标志位的值。关于nginx接收到信号之后如何设置对应的标志位，可以参照本人前面的文章(nginx master工作循环 超链接)，这里不再赘述。

3. 源码讲解

        master进程是通过ngx_start_worker_processes()方法启动各个子进程的，如下是该方法源码：

1. /**
2. * 启动n个worker子进程，并设置好每个子进程与master父进程之间使用socketpair
3. * 系统调用建立起来的socket句柄通信机制
4. */
5. static void ngx_start_worker_processes(ngx_cycle_t *cycle, ngx_int_t n, ngx_int_t type) {
6. ngx_int_t i;
7. ngx_channel_t ch;
8.  
9. ngx_memzero(&ch, sizeof(ngx_channel_t));
10. ch.command = NGX_CMD_OPEN_CHANNEL;
11.  
12. for (i = 0; i < n; i++) {
13.  
14. // spawn是产卵的意思，这里就是生成一个子进程的意思，而该子进程所进行的事件循环就是
15. // ngx_worker_process_cycle()方法，这里的ngx_worker_process_cycle是worker进程处理事件的循环，
16. // worker进程在一个无限for循环中，不断的检查相应的事件模型中是否存在对应的事件，
17. // 然后将accept事件和read、write事件分开放入两个队列中，最后在事件循环中不断的处理事件
18. ngx_spawn_process(cycle, ngx_worker_process_cycle,
19. (void *) (intptr_t) i, "worker process", type);
20.  
21. // 下面的这段代码的主要作用是将新建进程这个事件通知到其他的进程，上面的
22. // ch.command = NGX_CMD_OPEN_CHANNEL;中NGX_CMD_OPEN_CHANNEL表示的就是当前是新建了一个进程，
23. // 而ngx_process_slot存储的就是该新建进程所存放的数组位置，这里需要进行广播的原因在于，
24. // 每个子进程被创建后，其内存数据都是复制的父进程的，但是ngx_processes数组是每个进程都有一份的，
25. // 因而数组中先创建的子进程是没有后创建的子进程的数据的，但是master进程是有所有子进程的数据的，
26. // 因而这里master进程创建子进程之后，其就会向ngx_processes数组的每个进程的channel[0]上
27. // 写入当前广播的事件，也即这里的ch，通过这种方式，每个子进程接收到这个事件之后，
28. // 都会尝试更新其所保存的ngx_processes数据信息
29. ch.pid = ngx_processes[ngx_process_slot].pid;
30. ch.slot = ngx_process_slot;
31. ch.fd = ngx_processes[ngx_process_slot].channel[0];
32.  
33. // 广播事件
34. ngx_pass_open_channel(cycle, &ch);
35. }
36. }

        这里我们主要需要关注上面的启动子进程的方法调用，也即这里的ngx_spawn_process()方法，该方法的第二个参数是一个方法，在启动子进程之后，子进程就会进入该方法所指定的循环中。而在ngx_spawn_process()方法中，master进程会为当前新创建的子进程创建一个channel数组，以用于与当前子进程进行通信。如下是ngx_spawn_process()方法的源码：

1. ngx_pid_t ngx_spawn_process(ngx_cycle_t *cycle, ngx_spawn_proc_pt proc, void *data,char *name, ngx_int_t respawn) {
2. u_long on;
3. ngx_pid_t pid;
4. ngx_int_t s;
5.  
6. if (respawn >= 0) {
7. s = respawn;
8.  
9. } else {
10. // 在ngx_processes数组中存储了当前创建的所有进程，而ngx_last_process则是当前当前记录的最后一个
11. // process在ngx_processes中的下一个位置的索引，只不过ngx_processes中记录的进程有可能有部分
12. // 已经失效了。当前循环就是从头开始查找是否有某个进程已经失效了，如果已经失效了，则复用该进程位置，
13. // 否则直接使用ngx_last_process所指向的位置
14. for (s = 0; s < ngx_last_process; s++) {
15. if (ngx_processes[s].pid == -1) {
16. break;
17. }
18. }
19.  
20. // 这里说明所创建的进程数达到了最大限度
21. if (s == NGX_MAX_PROCESSES) {
22. ngx_log_error(NGX_LOG_ALERT, cycle->log, 0,
23. "no more than %d processes can be spawned",
24. NGX_MAX_PROCESSES);
25. return NGX_INVALID_PID;
26. }
27. }
28.  
29. // NGX_PROCESS_DETACHED标志表示当前fork出来的进程与原来的父进程没有任何关系，比如进行nginx升级时，
30. // 新生成的master进程就与原先的master进程没有关系
31. if (respawn != NGX_PROCESS_DETACHED) {
32.  
33. /* Solaris 9 still has no AF_LOCAL */
34.  
35. // 这里的socketpair()方法的主要作用是生成一对套接字流，用于主进程和子进程的通信，这一对套接字会
36. // 存储在ngx_processes[s].channel中，本质上这个字段是一个长度为2的整型数组。在主进程和子进程
37. // 进行通信的之前，主进程会关闭其中一个，而子进程会关闭另一个，然后相互之间往未关闭的另一个文件描述符中
38. // 写入或读取数据即可实现通信。
39. // AF_UNIX表示当前使用的是UNIX文件形式的socket地址族
40. // SOCK_STREAM指定了当前套接字建立的通信方式是管道流，并且这个管道流是双向的，
41. // 即管道双方都可以进行读写操作
42. // 第三个参数protocol必须为0
43. if (socketpair(AF_UNIX, SOCK_STREAM, 0, ngx_processes[s].channel) == -1) {
44. ngx_log_error(NGX_LOG_ALERT, cycle->log, ngx_errno,
45. "socketpair() failed while spawning \"%s\"", name);
46. return NGX_INVALID_PID;
47. }
48.  
49. ngx_log_debug2(NGX_LOG_DEBUG_CORE, cycle->log, 0,
50. "channel %d:%d",
51. ngx_processes[s].channel[0],
52. ngx_processes[s].channel[1]);
53.  
54. // 将ngx_processes[s].channel[0]设置为非阻塞模式
55. if (ngx_nonblocking(ngx_processes[s].channel[0]) == -1) {
56. ngx_log_error(NGX_LOG_ALERT, cycle->log, ngx_errno,
57. ngx_nonblocking_n
58. " failed while spawning \"%s\"",
59. name);
60. ngx_close_channel(ngx_processes[s].channel, cycle->log);
61. return NGX_INVALID_PID;
62. }
63.  
64. // 将ngx_processes[s].channel[1]设置为非阻塞模式
65. if (ngx_nonblocking(ngx_processes[s].channel[1]) == -1) {
66. ngx_log_error(NGX_LOG_ALERT, cycle->log, ngx_errno,
67. ngx_nonblocking_n
68. " failed while spawning \"%s\"",
69. name);
70. ngx_close_channel(ngx_processes[s].channel, cycle->log);
71. return NGX_INVALID_PID;
72. }
73.  
74. on = 1;
75. // 将ngx_processes[s].channel[0]套接字管道设置为异步模式
76. if (ioctl(ngx_processes[s].channel[0], FIOASYNC, &on) == -1) {
77. ngx_log_error(NGX_LOG_ALERT, cycle->log, ngx_errno,
78. "ioctl(FIOASYNC) failed while spawning \"%s\"", name);
79. ngx_close_channel(ngx_processes[s].channel, cycle->log);
80. return NGX_INVALID_PID;
81. }
82.  
83. // 当前还处于主进程中，这里的ngx_pid指向了主进程的进程id，当前方法的作用主要是将
84. // ngx_processes[s].channel[0]的操作权限设置给主进程，也就是说主进程通过向
85. // ngx_processes[s].channel[0]写入和读取数据来与子进程进行通信
86. if (fcntl(ngx_processes[s].channel[0], F_SETOWN, ngx_pid) == -1) {
87. ngx_log_error(NGX_LOG_ALERT, cycle->log, ngx_errno,
88. "fcntl(F_SETOWN) failed while spawning \"%s\"", name);
89. ngx_close_channel(ngx_processes[s].channel, cycle->log);
90. return NGX_INVALID_PID;
91. }
92.  
93. // FD_CLOEXEC表示当前指定的套接字管道在子进程中可以使用，但是在execl()执行的程序中不可使用
94. if (fcntl(ngx_processes[s].channel[0], F_SETFD, FD_CLOEXEC) == -1) {
95. ngx_log_error(NGX_LOG_ALERT, cycle->log, ngx_errno,
96. "fcntl(FD_CLOEXEC) failed while spawning \"%s\"",
97. name);
98. ngx_close_channel(ngx_processes[s].channel, cycle->log);
99. return NGX_INVALID_PID;
100. }
101.  
102. // FD_CLOEXEC表示当前指定的套接字管道在子进程中可以使用，但是在execl()执行的程序中不可使用
103. if (fcntl(ngx_processes[s].channel[1], F_SETFD, FD_CLOEXEC) == -1) {
104. ngx_log_error(NGX_LOG_ALERT, cycle->log, ngx_errno,
105. "fcntl(FD_CLOEXEC) failed while spawning \"%s\"",
106. name);
107. ngx_close_channel(ngx_processes[s].channel, cycle->log);
108. return NGX_INVALID_PID;
109. }
110.  
111. // ngx_processes[s].channel[1]是用于给子进程监听相关事件使用的，当父进程向
112. // ngx_processes[s].channel[0]发布事件之后，ngx_processes[s].channel[1]中就会接收到
113. // 对应的事件，从而进行相应的处理
114. ngx_channel = ngx_processes[s].channel[1];
115.  
116. } else {
117. // 如果是NGX_PROCESS_DETACHED模式，则表示当前是另外新起的一个master进程，因而将其管道值都置为-1
118. ngx_processes[s].channel[0] = -1;
119. ngx_processes[s].channel[1] = -1;
120. }
121.  
122. ngx_process_slot = s;
123.  
124.  
125. // fork()方法将产生一个新的进程，这个进程与父进程的关系是子进程的内存数据将完全复制父进程的。
126. // 还需要注意的是，fork()出来的子进程执行的代码是从fork()之后开始执行的，而对于父进程而言，
127. // 该方法的返回值为父进程id，而对于子进程而言，该方法返回值为0，因而通过if-else语句就可以让父进程
128. // 和子进程分别调用后续不同的代码片段
129. pid = fork();
130.  
131. switch (pid) {
132.  
133. case -1:
134. // fork出错
135. ngx_log_error(NGX_LOG_ALERT, cycle->log, ngx_errno,
136. "fork() failed while spawning \"%s\"", name);
137. ngx_close_channel(ngx_processes[s].channel, cycle->log);
138. return NGX_INVALID_PID;
139.  
140. case 0:
141. // 子进程执行的分支，这里的proc()方法是外部传进来的，也就是说，当前方法只是创建一个新的进程，
142. // 具体的进程处理逻辑，将交由外部代码块进行定义ngx_getpid()方法获取的就是当前新创建的子进程的进程id
143. ngx_pid = ngx_getpid();
144. proc(cycle, data);
145. break;
146.  
147. default:
148. // 父进程会走到这里
149. break;
150. }
151.  
152. ngx_log_error(NGX_LOG_NOTICE, cycle->log, 0, "start %s %P", name, pid);
153.  
154. // 父进程会走到这里，当前的pid是fork()之后父进程得到的新创建的子进程的pid
155. ngx_processes[s].pid = pid;
156. ngx_processes[s].exited = 0;
157.  
158. if (respawn >= 0) {
159. return pid;
160. }
161.  
162. // 设置当前进程的各个属性，并且存储到ngx_processes数组中的对应位置
163. ngx_processes[s].proc = proc;
164. ngx_processes[s].data = data;
165. ngx_processes[s].name = name;
166. ngx_processes[s].exiting = 0;
167.  
168. switch (respawn) {
169.  
170. case NGX_PROCESS_NORESPAWN:
171. ngx_processes[s].respawn = 0;
172. ngx_processes[s].just_spawn = 0;
173. ngx_processes[s].detached = 0;
174. break;
175.  
176. case NGX_PROCESS_JUST_SPAWN:
177. ngx_processes[s].respawn = 0;
178. ngx_processes[s].just_spawn = 1;
179. ngx_processes[s].detached = 0;
180. break;
181.  
182. case NGX_PROCESS_RESPAWN:
183. ngx_processes[s].respawn = 1;
184. ngx_processes[s].just_spawn = 0;
185. ngx_processes[s].detached = 0;
186. break;
187.  
188. case NGX_PROCESS_JUST_RESPAWN:
189. ngx_processes[s].respawn = 1;
190. ngx_processes[s].just_spawn = 1;
191. ngx_processes[s].detached = 0;
192. break;
193.  
194. case NGX_PROCESS_DETACHED:
195. ngx_processes[s].respawn = 0;
196. ngx_processes[s].just_spawn = 0;
197. ngx_processes[s].detached = 1;
198. break;
199. }
200.  
201. if (s == ngx_last_process) {
202. ngx_last_process++;
203. }
204.  
205. return pid;
206. }
207.  

        ngx_spawn_process()方法最后会fork()一个子进程以执行其第二个参数所指定的回调方法。但是在这之前，我们需要说明的是，其通过socketpair()方法调用会创建一对匿名的socket，然后将其存储在当前进程的channel数组中，如此就完成了channel数组的创建。

        worker进程启动之后会执行ngx_worker_process_cycle()方法，该方法首先会对worker进程进行初始化，其中就包括对继承而来的channel数组的处理。由于master进程和worker进程都保有channel数组所指代的socket描述符，而本质上master进程和各个worker进程只需要保有该数组的某一边的描述符即可。因而这里worker进程在初始化过程中，会关闭其所保存的另一边的描述符。在nginx中，master进程统一的会保留channel数组的0号位的socket描述符，关闭1号位的socket描述符，而worker进程则会关闭0号位的socket描述符，保留1号位的描述符。这样master进程需要与worker进程通信时，就只需要往channel[0]中写入数据，而worker进程则会监听channel[1]，从而接收到master进程的数据写入。这里我们首先看一下worker进程的初始化方法ngx_worker_process_init()的源码：

1. /**
2. * 这里主要是对当前进程进行初始化，为其设置优先级和打开的文件限制等参数。
3. * 最后会为当前进程添加一个监听channel[1]的连接，以不断读取master进程的消息，从而进行相应的处理
4. */
5. static void ngx_worker_process_init(ngx_cycle_t *cycle, ngx_int_t worker) {
6. sigset_t set;
7. ngx_int_t n;
8. ngx_time_t *tp;
9. ngx_uint_t i;
10. ngx_cpuset_t *cpu_affinity;
11. struct rlimit rlmt;
12. ngx_core_conf_t *ccf;
13. ngx_listening_t *ls;
14.  
15. // 设置时区相关的信息
16. if (ngx_set_environment(cycle, NULL) == NULL) {
17. /* fatal */
18. exit(2);
19. }
20.  
21. ccf = (ngx_core_conf_t *) ngx_get_conf(cycle->conf_ctx, ngx_core_module);
22.  
23. // 设置当前进程的优先级
24. if (worker >= 0 && ccf->priority != 0) {
25. if (setpriority(PRIO_PROCESS, 0, ccf->priority) == -1) {
26. ngx_log_error(NGX_LOG_ALERT, cycle->log, ngx_errno,
27. "setpriority(%d) failed", ccf->priority);
28. }
29. }
30.  
31. // 设置当前进程能够打开的文件句柄数
32. if (ccf->rlimit_nofile != NGX_CONF_UNSET) {
33. rlmt.rlim_cur = (rlim_t) ccf->rlimit_nofile;
34. rlmt.rlim_max = (rlim_t) ccf->rlimit_nofile;
35.  
36. if (setrlimit(RLIMIT_NOFILE, &rlmt) == -1) {
37. ngx_log_error(NGX_LOG_ALERT, cycle->log, ngx_errno,
38. "setrlimit(RLIMIT_NOFILE, %i) failed",
39. ccf->rlimit_nofile);
40. }
41. }
42.  
43. // Changes the limit on the largest size of a core file(RLIMIT_CORE) for worker processes.
44. // 简而言之就是设置核心文件能够使用的最大大小
45. if (ccf->rlimit_core != NGX_CONF_UNSET) {
46. rlmt.rlim_cur = (rlim_t) ccf->rlimit_core;
47. rlmt.rlim_max = (rlim_t) ccf->rlimit_core;
48.  
49. if (setrlimit(RLIMIT_CORE, &rlmt) == -1) {
50. ngx_log_error(NGX_LOG_ALERT, cycle->log, ngx_errno,
51. "setrlimit(RLIMIT_CORE, %O) failed",
52. ccf->rlimit_core);
53. }
54. }
55.  
56. // geteuid()返回执行当前程序的用户id，这里的0表示是否为root用户
57. if (geteuid() == 0) {
58. // setgid()方法的作用是更改组的id
59. if (setgid(ccf->group) == -1) {
60. ngx_log_error(NGX_LOG_EMERG, cycle->log, ngx_errno,
61. "setgid(%d) failed", ccf->group);
62. /* fatal */
63. exit(2);
64. }
65.  
66. // initgroups()是更改附加组的id
67. if (initgroups(ccf->username, ccf->group) == -1) {
68. ngx_log_error(NGX_LOG_EMERG, cycle->log, ngx_errno,
69. "initgroups(%s, %d) failed",
70. ccf->username, ccf->group);
71. }
72.  
73. // 更改用户的id
74. if (setuid(ccf->user) == -1) {
75. ngx_log_error(NGX_LOG_EMERG, cycle->log, ngx_errno,
76. "setuid(%d) failed", ccf->user);
77. /* fatal */
78. exit(2);
79. }
80. }
81.  
82. // 需要注意的是，对于cache manager和cache loader进程，这里的worker传入的是-1，
83. // 表示这两个进程不需要设置亲核性
84. if (worker >= 0) {
85. // 获取当前worker的CPU亲核性
86. cpu_affinity = ngx_get_cpu_affinity(worker);
87.  
88. if (cpu_affinity) {
89. // 设置worker的亲核心
90. ngx_setaffinity(cpu_affinity, cycle->log);
91. }
92. }
93.  
94. #if (NGX_HAVE_PR_SET_DUMPABLE)
95. if (prctl(PR_SET_DUMPABLE, 1, 0, 0, 0) == -1) {
96. ngx_log_error(NGX_LOG_ALERT, cycle->log, ngx_errno,
97. "prctl(PR_SET_DUMPABLE) failed");
98. }
99.  
100. #endif
101.  
102. if (ccf->working_directory.len) {
103. // chdir()的作用是将当前的工作目录更改为其参数所传入的路径
104. if (chdir((char *) ccf->working_directory.data) == -1) {
105. ngx_log_error(NGX_LOG_ALERT, cycle->log, ngx_errno,
106. "chdir(\"%s\") failed", ccf->working_directory.data);
107. /* fatal */
108. exit(2);
109. }
110. }
111.  
112. // 初始化空的set指令集合
113. sigemptyset(&set);
114.  
115. // ◆ SIG_BLOCK：将 set 参数指向信号集中的信号加入到信号掩码中。
116. // ◆ SIG_UNBLOCK：将 set 参数指向的信号集中的信号从信号掩码中删除。
117. // ◆ SIG_SETMASK：将 set 参数指向信号集设置为信号掩码。
118. // 这里就是直接初始化要阻塞的信号集，默认为空集
119. if (sigprocmask(SIG_SETMASK, &set, NULL) == -1) {
120. ngx_log_error(NGX_LOG_ALERT, cycle->log, ngx_errno,
121. "sigprocmask() failed");
122. }
123.  
124. tp = ngx_timeofday();
125. srandom(((unsigned) ngx_pid << 16) ^ tp->sec ^ tp->msec);
126.  
127. ls = cycle->listening.elts;
128. for (i = 0; i < cycle->listening.nelts; i++) {
129. ls[i].previous = NULL;
130. }
131.  
132. // 这里调用各个模块的init_process()方法进行进程模块的初始化
133. for (i = 0; cycle->modules[i]; i++) {
134. if (cycle->modules[i]->init_process) {
135. if (cycle->modules[i]->init_process(cycle) == NGX_ERROR) {
136. /* fatal */
137. exit(2);
138. }
139. }
140. }
141.  
142. // 这里主要是关闭当前进程中其他各个进程的channel[1]管道句柄
143. for (n = 0; n < ngx_last_process; n++) {
144.  
145. if (ngx_processes[n].pid == -1) {
146. continue;
147. }
148.  
149. if (n == ngx_process_slot) {
150. continue;
151. }
152.  
153. if (ngx_processes[n].channel[1] == -1) {
154. continue;
155. }
156.  
157. if (close(ngx_processes[n].channel[1]) == -1) {
158. ngx_log_error(NGX_LOG_ALERT, cycle->log, ngx_errno,
159. "close() channel failed");
160. }
161. }
162.  
163. // 关闭当前进程的channel[0]管道句柄
164. if (close(ngx_processes[ngx_process_slot].channel[0]) == -1) {
165. ngx_log_error(NGX_LOG_ALERT, cycle->log, ngx_errno,
166. "close() channel failed");
167. }
168.  
169. #if 0
170. ngx_last_process = 0;
171. #endif
172.  
173. // ngx_channel指向的是当前进程的channel[1]句柄，也即监听master进程发送消息的句柄。
174. // 当前方法中，首先会为当前的句柄创建一个connection对象，并且将其封装为一个事件，然后将该事件添加到
175. // 对应的事件模型队列中以监听当前句柄的事件，事件的处理逻辑则主要有这里的ngx_channel_handler()
176. // 方法进行。这里的ngx_channel_handler的主要处理逻辑是，根据当前收到的消息设置当前进程的一些标志位，
177. // 或者更新某些缓存数据，如此，在当前进行的事件循环中，通过不断检查这些标志位，从而实现在事件进程中
178. // 处理真正的逻辑。因而这里的ngx_channel_handler的处理效率是非常高的
179. if (ngx_add_channel_event(cycle, ngx_channel, NGX_READ_EVENT,
180. ngx_channel_handler)
181. == NGX_ERROR) {
182. /* fatal */
183. exit(2);
184. }
185. }
186.  

        该方法主要是对worker进程进行初始化，这里我们主要需要关注最后会遍历ngx_processes数组，这个数组中保存了当前nginx中各个进程的相关信息。在遍历过程中，会关闭当前进程保有的其余进程的channel[1]句柄，而保留有channel[0]句柄，这样当前进程如果需要与其他进程通信，也只需要往目标进程的channel[0]中写入数据即可。在遍历完成之后，当前进程就会关闭自身的channel[0]句柄，而保留channel[1]句柄。最后，会通过ngx_add_channel_event()方法为当前进程添加对channel[1]的监听事件，这里在调用ngx_add_channel_event()方法时传入的第二个参数是ngx_channel，该参数是在前面的ngx_spawn_process()方法中赋值的，指向的就是当前进程的channel[1]的socket句柄。

        关于ngx_add_channel_event()方法，其本质就是创建一个ngx_event_t结构体的事件，然后将其添加到当前所使用的事件模型（比如epoll）句柄中。这里不再赘述该方法的实现源码，不过我们需要关注的是该事件触发时的回调方法，即调用ngx_add_channel_event()方法时传入的第三个参数ngx_channel_handler()方法。如下是该方法的源码：

1. static void ngx_channel_handler(ngx_event_t *ev) {
2. ngx_int_t n;
3. ngx_channel_t ch;
4. ngx_connection_t *c;
5.  
6. if (ev->timedout) {
7. ev->timedout = 0;
8. return;
9. }
10.  
11. c = ev->data;
12.  
13. for (;;) {
14.  
15. // 在无限for循环中不断读取master进程发过来的消息
16. n = ngx_read_channel(c->fd, &ch, sizeof(ngx_channel_t), ev->log);
17.  
18. // 如果读取消息出错，说明当前的句柄可能失效了，就需要关闭当前连接
19. if (n == NGX_ERROR) {
20. if (ngx_event_flags & NGX_USE_EPOLL_EVENT) {
21. ngx_del_conn(c, 0);
22. }
23.  
24. ngx_close_connection(c);
25. return;
26. }
27.  
28. if (ngx_event_flags & NGX_USE_EVENTPORT_EVENT) {
29. if (ngx_add_event(ev, NGX_READ_EVENT, 0) == NGX_ERROR) {
30. return;
31. }
32. }
33.  
34. if (n == NGX_AGAIN) {
35. return;
36. }
37.  
38. // 对发送过来的消息进行处理
39. switch (ch.command) {
40. // 如果是quit消息，则设置quit标志位
41. case NGX_CMD_QUIT:
42. ngx_quit = 1;
43. break;
44.  
45. // 如果terminate消息，则设置terminate标志位
46. case NGX_CMD_TERMINATE:
47. ngx_terminate = 1;
48. break;
49.  
50. // 如果是reopen消息，则设置reopen标志位
51. case NGX_CMD_REOPEN:
52. ngx_reopen = 1;
53. break;
54.  
55. // 如果是新建进程消息，则更新当前ngx_processes数组对应位置的数据
56. case NGX_CMD_OPEN_CHANNEL:
57. ngx_processes[ch.slot].pid = ch.pid;
58. ngx_processes[ch.slot].channel[0] = ch.fd;
59. break;
60.  
61. // 如果是关闭channel的消息，则关闭ngx_processes数组对应位置的句柄
62. case NGX_CMD_CLOSE_CHANNEL:
63. if (close(ngx_processes[ch.slot].channel[0]) == -1) {
64. ngx_log_error(NGX_LOG_ALERT, ev->log, ngx_errno,
65. "close() channel failed");
66. }
67.  
68. ngx_processes[ch.slot].channel[0] = -1;
69. break;
70. }
71. }
72. }
73.  

        在ngx_channel_handler()方法中，主要是读取所监听的socket句柄中的数据，而数据是以一个ngx_channel_t结构体所承载的，这个ngx_channel_t是nginx所统一使用的master与worker进程进行通信的结构体，其会指定当前发生的事件类型，以及发生该事件的进程信息。如下是ngx_channel_t结构体的声明：

1. typedef struct {
2. // 当前发生的事件类型
3. ngx_uint_t command;
4. // 发生事件的pid
5. ngx_pid_t pid;
6. // 发生事件的进程在ngx_processes数组中的下标
7. ngx_int_t slot;
8. // 发生事件的进程的channel[0]描述符的值
9. ngx_fd_t fd;
10. } ngx_channel_t;

       在从当前进程的channel[1]中读取了ngx_channel_t结构体的数据之后，ngx_channel_handler()方法会根据发生的事件类型更新相应的标志位的状态，并且会更新当前进程的ngx_processes数组中对应的发生事件的进程的状态信息。

        在处理了master进程所发送的事件之后，worker进程就会继续其循环，在该循环中会检查其所关注的标志位的状态，然后会根据这些状态执行对应的逻辑。如下是worker进程工作的循环的源码：

1. /**
2. * 进入worker进程工作的循环
3. */
4. static void ngx_worker_process_cycle(ngx_cycle_t *cycle, void *data) {
5. ngx_int_t worker = (intptr_t) data;
6.  
7. ngx_process = NGX_PROCESS_WORKER;
8. ngx_worker = worker;
9.  
10. // 初始化worker进程，前面对该方法的源码进行了讲解
11. ngx_worker_process_init(cycle, worker);
12.  
13. ngx_setproctitle("worker process");
14.  
15. for (;;) {
16.  
17. if (ngx_exiting) {
18. // 这里主要是检查有没有事件是非cancelable状态的，也就是说是否所有的事件都已经取消了，如果取消了，
19. // 就会返回NGX_OK。这里的逻辑可以理解为，如果被标记为了ngx_exiting，那么此时，如果还有未取消的
20. // 事件存在，则会走到下面的ngx_process_events_and_timers()方法，如此就会处理未完成的事件，
21. // 然后在循环中再次走到这个位置，最终if条件为true，从而执行退出worker进程的工作
22. if (ngx_event_no_timers_left() == NGX_OK) {
23. ngx_log_error(NGX_LOG_NOTICE, cycle->log, 0, "exiting");
24. ngx_worker_process_exit(cycle);
25. }
26. }
27.  
28. ngx_log_debug0(NGX_LOG_DEBUG_EVENT, cycle->log, 0, "worker cycle");
29.  
30. // 这里通过检查相应的事件模型中是否存在对应的事件，然后将其放入队列中进行处理，
31. // 这里是worker进程处理事件的核心方法
32. ngx_process_events_and_timers(cycle);
33.  
34. // 这里ngx_terminate是强制关闭nginx的选项，如果向nginx发送了强制关闭nginx命令，则当前进程会直接退出
35. if (ngx_terminate) {
36. ngx_log_error(NGX_LOG_NOTICE, cycle->log, 0, "exiting");
37. ngx_worker_process_exit(cycle);
38. }
39.  
40. // 这里ngx_quit是优雅退出的选项。这里主要是将ngx_exiting置为1，用于表征当前进程需要退出，
41. // 然后会执行如下三个工作：
42. // 1. 往事件队列中添加一个事件，用于处理当前处于活跃状态的连接，将其close标志位置为1，并且执行该连接
43. // 当前的处理方法，以尽快完成连接事件；
44. // 2. 关闭当前cycle中监听的socket句柄；
45. // 3. 将当前所有处于空闲状态的连接的close状态标记为1，然后调用其连接处理方法.
46. if (ngx_quit) {
47. ngx_quit = 0;
48. ngx_log_error(NGX_LOG_NOTICE, cycle->log, 0, "gracefully shutting down");
49. ngx_setproctitle("worker process is shutting down");
50.  
51. if (!ngx_exiting) {
52. ngx_exiting = 1;
53. ngx_set_shutdown_timer(cycle);
54. ngx_close_listening_sockets(cycle);
55. ngx_close_idle_connections(cycle);
56. }
57. }
58.  
59. // ngx_reopen主要是重新打开nginx的所有文件，比如切换nginx的日志文件等等
60. if (ngx_reopen) {
61. ngx_reopen = 0;
62. ngx_log_error(NGX_LOG_NOTICE, cycle->log, 0, "reopening logs");
63. ngx_reopen_files(cycle, -1);
64. }
65. }
66. }
67.  

        可以看到，worker进程主要处理了nginx是否退出相关的标志位，还处理了nginx是否重新读取了配置文件的标志位。

4. 小结

        本文首先对master-worker进程交互的基本原理进行了讲解，然后深入到源码中讲解了nginx是如何实现master和worker进程的相互通信的。

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持我们。