首页 > nginx, 源码分析 > nginx的执行模型

nginx的执行模型

2011年9月10日 发表评论 阅读评论 4,565 次浏览

请关注最新修正合订:http://lenky.info/ebook/
这一系列的文章还是在09年写的,存在电脑里很久了,现在贴出来。顺序也不记得了,看到那个就发那个吧,最近都会发上来。欢迎转载,但请保留链接:http://lenky.info/,谢谢。
Nginx的进程模型和大多数同类服务程序一样,按职责将进程分成监控进程和工作进程两类。在多进程模型下,主进程就充当监控进程,而由主进程fork出来的子进程则充当工作进程;在单进程模型下,主进程就是工作进程,此时没有监控进程。Nginx的单进程模型比较简单,下面主要分析多进程模型。

分析Nginx多进程模型的入口函数为主进程的ngx_master_process_cycle,在该函数做完信号处理设置等之后就会调用一个名为ngx_start_worker_processes的函数用于fork产生出子进程(子进程数目通过函数调用的第二个参数指定),子进程作为一个新的实体开始充当工作进程的角色处理客户端的服务请求;而主进程继续执行ngx_master_process_cycle函数,也就是作为监控进程执行主体for循环,这是一个死循环,直到进程终止才退出,服务进程基本都是这种写法,所以不用详述,下面先看看这个模型的图示:

图示里表现得很明朗,监控进程和工作进程各有一个无限for循环,以便进程持续的等待和处理自己负责的事务,直到进程退出。
监控进程的无限for循环内有一个关键的sigsuspend函数调用,该函数的调用使得监控进程的大部分时间都处于挂起状态,直到监控进程接收到信号为止,当监控进程接收到信号时,调用信号处理函数ngx_signal_handler进行处理。我们知道,信号处理函数一般都比较简单,故此在函数ngx_signal_handler内执行的动作主要也就是对一些标识字段进行设置,而更具体的处理逻辑仍直接放在for循环内,所以该for循环接下来的代码就是判断那些标识字段,比如ngx_reap(有子进程退出?)、ngx_quit或ngx_terminate(进行要退出或终止?)、ngx_reconfigure(重新加载配置?)等是否被置位并相应的做出处理。当所有信号都处理完时又挂起在函数sigsuspend调用处继续等待新的信号,如此反复,构成监控进程的主要执行体。
工作进程的执行主体与监控进程类似,不过工作进程既然是工作进程,那么它的主要关注点就是与客户端之间的数据可读/可写事件,而不是信号,所以,工作进程的阻塞点是在像select、epoll_wait等这样的函数调用处,以等待发生数据可读/可写事件或是被新收到的信号中断。Nginx的IO复用模型封装得相当不错,当然也非一两句言语能够说得清楚,这将在我们的IO复用模型的统一一章做详细介绍。

转载请保留地址:http://www.lenky.info/archives/2011/09/48http://lenky.info/?p=48


备注:如无特殊说明,文章内容均出自Lenky个人的真实理解而并非存心妄自揣测来故意愚人耳目。由于个人水平有限,虽力求内容正确无误,但仍然难免出错,请勿见怪,如果可以则请留言告之,并欢迎来讨论。另外值得说明的是,Lenky的部分文章以及部分内容参考借鉴了网络上各位网友的热心分享,特别是一些带有完全参考的文章,其后附带的链接内容也许更直接、更丰富,而我只是做了一下归纳&转述,在此也一并表示感谢。关于本站的所有技术文章,欢迎转载,但请遵从CC创作共享协议,而一些私人性质较强的心情随笔,建议不要转载。

法律:根据最新颁布的《信息网络传播权保护条例》,如果您认为本文章的任何内容侵犯了您的权利,请以Email或书面等方式告知,本站将及时删除相关内容或链接。

分类: nginx, 源码分析 标签: ,
  1. 本文目前尚无任何评论.
  1. 本文目前尚无任何 trackbacks 和 pingbacks.