Nginx是一个高性能的HTTP和反向代理服务器，也是一个IMAP/POP3/SMTP服务器 Nginx是一款轻量级的Web服务器/反向代理服务器及电子邮件（IMAP/POP3）代理服务器
跨平台、配置简单非阻塞、高并发连接：处理2-3万并发连接数，官方监测能支持5万并发内存消耗小：开启10个nginx才占150M内存 成本低廉：开源内置的健康检查功能：如果有一个服务器宕机，会做一个健康检查，再发送的请求就不会发送到宕机的服务器了。重新将请求提交到其他的节点上。 节省宽带：支持GZIP压缩，可以添加浏览器本地缓存 稳定性高：宕机的概率非常小master/worker结构：一个master进程，生成一个或者多个worker进程 接收用户请求是异步的：浏览器将请求发送到nginx服务器，它先将用户请求全部接收下来，再一次性发送给后端web服务器，极大减轻了web服务器的压力 一边接收web服务器的返回数据，一边发送给浏览器客户端 网络依赖性比较低，只要ping通就可以负载均衡 可以有多台nginx服务器事件驱动：通信机制采用epoll模型
首先，nginx在启动时，会解析配置文件，得到需要监听的端口与ip地址，然后在nginx的master进程里面 先初始化好这个监控的socket(创建socket，设置addrreuse等选项，绑定到指定的ip地址端口，再listen) 然后再fork(一个现有进程可以调用fork函数创建一个新进程。由fork创建的新进程被称为子进程 )出多个子进程出来 然后子进程会竞争accept新的连接。此时，客户端就可以向nginx发起连接了。当客户端与nginx进行三次握手，与nginx建立好一个连接后 此时，某一个子进程会accept成功，得到这个建立好的连接的socket，然后创建nginx对连接的封装，即ngx_connection_t结构体 接着，设置读写事件处理函数并添加读写事件来与客户端进行数据的交换。最后，nginx或客户端来主动关掉连接，到此，一个连接就寿终正寝了
表面上看，当Nginx处理一个来自客户端的请求时，先根据请求头的host、ip和port来确定由哪个server处理， 确定了server之后，再根据请求的uri找到对应的location，这个请求就由这个location处理。 实际Nginx将一个请求的处理划分为若干个不同阶段（phase），这些阶段按照前后顺序依次执行，也就是说NGX_HTTP_POST_READ_PHASE在第一个，NGX_HTTP_LOG_PHASE在最后一个。
Nginx 默认采用守护模式启动，守护模式让master进程启动后在后台运行，不在窗口上卡住。 Nginx 启动后会有一个 Master 进程和多个Worker 进程，Master 进程主要用来管理 Worker 进程，对网络事件进程进行收集和分发，调度哪个模块可以占用 CPU 资源，从而处理请求。一般配置Worker进程的个数与机器cpu个数一致，从而打到cpu资源的最大化利用，也避免由于进程资源分配带来的额外开销。
惊群现象:当listen_fd有新的accept()请求过来,操作系统会唤醒所有子进程,因为这些进程都epoll_wait()同一个listen_fd,操作系统又无从判断由谁来负责accept,索性干脆全部叫醒,但最终只会有一个进程成功accept,其他进程accept失败.所有子进程都是被"吓醒"的,所以称之为Thundering Herd(惊群).
Nginx解决惊群的思路:避免惊群. 使用全局互斥锁(accept_mutex on),每个工作进程在epoll_wait()之前先去申请锁,申请到则继续处理,获取不到则等待,并设置了一个负载均衡的算法(当某一个工作进程的任务量达到总设置量的7/8时,则不会再尝试去申请锁)来均衡各个进程的任务量.
当一个worker进程在accept这个连接之后，就开始读取请求，解析请求，处理请求，产生数据后，再返回给客户端，最后才断开连接，这样一个完整的请求就是这样的了。我们可以看到，一个请求，完全由worker进程来处理，而且只在一个worker进程中处理。
采用这种方式的好处：
节省锁带来的开销。对于每个worker进程来说，独立的进程，不需要加锁，所以省掉了锁带来的开销，同时在编程以及问题查上时，也会方便很多独立进程，减少风险。采用独立的进程，可以让互相之间不会影响，一个进程退出后，其它进程还在工作，服务不会中断，master进程则很快重新启动新的worker进程在一次请求里无需进程切换一个请求的基本过程：建立连接 - 接受连接 - 发送数据，在系统底层就是读写事件。
Epoll 模型
Epoll出现在 linux2.6以后，Nginx采用 Epoll 这种异步非阻塞的事件处理机制。这种机制的原理就是把一个完整的请求，划分成多个事件，比如accept（）， recv（），磁盘I/O，send（），每个事件都有不同的模块进行处理。一个请求由一个worker进程处理，在请求多的时候，无需频繁的切换进程。
master进程先建好需要listen的socket后，然后再fork出多个woker进程，这样每个work进程都可以去accept这个socket当一个client连接到来时，所有accept的work进程都会受到通知，但只有一个进程可以accept成功，其它的则会accept失败，Nginx提供了一把共享锁accept_mutex来保证同一时刻只有一个work进程在accept连接，从而解决惊群问题当一个worker进程accept这个连接后，就开始读取请求，解析请求，处理请求，产生数据后，再返回给客户端，最后才断开连接，这样一个完成的请求就结束了Epoll 是基于一个进程处理多个连接、非阻塞IO的策略，Nginx多使用这种策略。
Select 模型
Select 模型在启动的时候创建多个进程，放在一个进程池里，并且进程池里的进程数会随着请求数目的增加而增加，对于每一个连接，都是在一个进程内处理完毕。所以Select模型能接收的并发量受到所能开启的进程数影响，进程之间是互相阻塞的，且频繁的切换进程造成大量开销。
Select 是基于一个线程处理一个请求的非阻塞IO的策略，Apache使用这种策略。
最大连接数
当作为http服务器的时候：max_clients = worker_processes * worker_connections; 当作为反向代理的时候：max_clients = worker_processes * worker_connections/4
nginx的upstream目前支持的5种方式的分配:
轮询（默认） 每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。 upstream backserver { server host:port; server host:port; }weight 指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况upstream backserver { server host:port weight=10; server host:port weight=10; }
ip_hash 每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题 upstream backserver { ip_hash; server host:port; server host:port; }fair（第三方） 按后端服务器的响应时间来分配请求，响应时间短的优先分配。upstream backserver { server server1; server server2; fair; }
url_hash（第三方） 按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存时比较有效upstream backserver { server squid1:3128; server squid2:3128; hash $request_uri; hash_method crc32; }
# 代理缓冲区相关配置 proxy_buffer_size 128k; proxy_buffers 4 256k; proxy_busy_buffers_size 256k; # 通过令牌桶原理实现用户访问次数限制 limit_req_zone $http_x_forwarded_for zone=req_one:10m rate=30r/s; #设置Web缓存区名称为cache_web，内存缓存空间大小为300MB，1天没有被访问的内容自动清除，硬盘缓存空间 #大小为3GB。 proxy_temp_path /xxx/proxy_temp_dir 1 2; proxy_cache_path /xxx/proxy_cache_dir levels=1:2 keys_zone=cache_web:300m inactive=1d max_size=1g;
location ~ /.ht { deny all; }
通过 upstream 可以设定后端服务器，指定的方式可以是 IP 地址与端口、域名、UNIX 套接字（socket）。其中如果域名可以被解析为多个地址，则这些地址都作为 backend。下面举例说明：
upstream backend { server blog.csdn.net/poechant; server 145.223.156.89:8090; server unix:/tmp/backend3; }
分为轮询（round robin）、用户 IP 哈希（client IP）和指定权重 3 种方式，默认情况下，提供轮询作为负载均衡策略。
可以为每个 backend 指定最大的重试次数，和重试时间间隔。所使用的关键字是 max_fails 和 fail_timeout。如下所示： upstream backend { server backend1.example.com weight=5; server 54.244.56.3:8081 max_fails=3 fail_timeout=30s; }
可以使用“backup”关键字。当所有的非备机（non-backup）都宕机（down）或者繁忙（busy）的时候，就只使用由 backup 标注的备机。必须要注意的是，backup 不能和 ip_hash 关键字一起使用。举例如下： upstream backend { server backend1.example.com; server backend2.example.com backup; server backend3.example.com; }
######Nginx配置文件nginx.conf中文详解##### #定义Nginx运行的用户和用户组 user www www; #nginx进程数，建议设置为等于CPU总核心数。 worker_processes 8; #全局错误日志定义类型，[ debug | info | notice | warn | error | crit ] error_log /usr/local/nginx/logs/error.log info; #进程pid文件 pid /usr/local/nginx/logs/nginx.pid; #指定进程可以打开的最大描述符：数目 #工作模式与连接数上限 #这个指令是指当一个nginx进程打开的最多文件描述符数目，理论值应该是最多打开文件数（ulimit -n）与nginx进程数相除，但是nginx分配请求并不是那么均匀，所以最好与ulimit -n 的值保持一致。 #现在在linux 2.6内核下开启文件打开数为65535，worker_rlimit_nofile就相应应该填写65535。 #这是因为nginx调度时分配请求到进程并不是那么的均衡，所以假如填写10240，总并发量达到3-4万时就有进程可能超过10240了，这时会返回502错误。 worker_rlimit_nofile 65535; events { #参考事件模型，use [ kqueue | rtsig | epoll | /dev/poll | select | poll ]; epoll模型 #是Linux 2.6以上版本内核中的高性能网络I/O模型，linux建议epoll，如果跑在FreeBSD上面，就用kqueue模型。 #补充说明： #与apache相类，nginx针对不同的操作系统，有不同的事件模型 #A）标准事件模型 #Select、poll属于标准事件模型，如果当前系统不存在更有效的方法，nginx会选择select或poll #B）高效事件模型 #Kqueue：使用于FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 和 MacOS X.使用双处理器的MacOS X系统使用kqueue可能会造成内核崩溃。 #Epoll：使用于Linux内核2.6版本及以后的系统。 #/dev/poll：使用于Solaris 7 11/99+，HP/UX 11.22+ (eventport)，IRIX 6.5.15+ 和 Tru64 UNIX 5.1A+。 #Eventport：使用于Solaris 10。 为了防止出现内核崩溃的问题， 有必要安装安全补丁。 use epoll; #单个进程最大连接数（最大连接数=连接数*进程数） #根据硬件调整，和前面工作进程配合起来用，尽量大，但是别把cpu跑到100%就行。每个进程允许的最多连接数，理论上每台nginx服务器的最大连接数为。 worker_connections 65535; #keepalive超时时间。 keepalive_timeout 60; #客户端请求头部的缓冲区大小。这个可以根据你的系统分页大小来设置，一般一个请求头的大小不会超过1k，不过由于一般系统分页都要大于1k，所以这里设置为分页大小。 #分页大小可以用命令getconf PAGESIZE 取得。 #[root@web001 ~]# getconf PAGESIZE #4096 #但也有client_header_buffer_size超过4k的情况，但是client_header_buffer_size该值必须设置为“系统分页大小”的整倍数。 client_header_buffer_size 4k; #这个将为打开文件指定缓存，默认是没有启用的，max指定缓存数量，建议和打开文件数一致，inactive是指经过多长时间文件没被请求后删除缓存。 open_file_cache max=65535 inactive=60s; #这个是指多长时间检查一次缓存的有效信息。 #语法:open_file_cache_valid time 默认值:open_file_cache_valid 60 使用字段:http, server, location 这个指令指定了何时需要检查open_file_cache中缓存项目的有效信息. open_file_cache_valid 80s; #open_file_cache指令中的inactive参数时间内文件的最少使用次数，如果超过这个数字，文件描述符一直是在缓存中打开的，如上例，如果有一个文件在inactive时间内一次没被使用，它将被移除。 #语法:open_file_cache_min_uses number 默认值:open_file_cache_min_uses 1 使用字段:http, server, location 这个指令指定了在open_file_cache指令无效的参数中一定的时间范围内可以使用的最小文件数,如果使用更大的值,文件描述符在cache中总是打开状态. open_file_cache_min_uses 1; #语法:open_file_cache_errors on | off 默认值:open_file_cache_errors off 使用字段:http, server, location 这个指令指定是否在搜索一个文件是记录cache错误. open_file_cache_errors on; } #设定http服务器，利用它的反向代理功能提供负载均衡支持 http { #文件扩展名与文件类型映射表 include mime.types; #默认文件类型 default_type application/octet-stream; #默认编码 #charset utf-8; #服务器名字的hash表大小 #保存服务器名字的hash表是由指令server_names_hash_max_size 和server_names_hash_bucket_size所控制的。参数hash bucket size总是等于hash表的大小，并且是一路处理器缓存大小的倍数。在减少了在内存中的存取次数后，使在处理器中加速查找hash表键值成为可能。如果hash bucket size等于一路处理器缓存的大小，那么在查找键的时候，最坏的情况下在内存中查找的次数为2。第一次是确定存储单元的地址，第二次是在存储单元中查找键 值。因此，如果Nginx给出需要增大hash max size 或 hash bucket size的提示，那么首要的是增大前一个参数的大小. server_names_hash_bucket_size 128; #客户端请求头部的缓冲区大小。这个可以根据你的系统分页大小来设置，一般一个请求的头部大小不会超过1k，不过由于一般系统分页都要大于1k，所以这里设置为分页大小。分页大小可以用命令getconf PAGESIZE取得。 client_header_buffer_size 32k; #客户请求头缓冲大小。nginx默认会用client_header_buffer_size这个buffer来读取header值，如果header过大，它会使用large_client_header_buffers来读取。 large_client_header_buffers 4 64k; #设定通过nginx上传文件的大小 client_max_body_size 8m; #开启高效文件传输模式，sendfile指令指定nginx是否调用sendfile函数来输出文件，对于普通应用设为 on，如果用来进行下载等应用磁盘IO重负载应用，可设置为off，以平衡磁盘与网络I/O处理速度，降低系统的负载。注意：如果图片显示不正常把这个改成off。 #sendfile指令指定 nginx 是否调用sendfile 函数（zero copy 方式）来输出文件，对于普通应用，必须设为on。如果用来进行下载等应用磁盘IO重负载应用，可设置为off，以平衡磁盘与网络IO处理速度，降低系统uptime。 sendfile on; #开启目录列表访问，合适下载服务器，默认关闭。 autoindex on; #此选项允许或禁止使用socke的TCP_CORK的选项，此选项仅在使用sendfile的时候使用 tcp_nopush on; tcp_nodelay on; #长连接超时时间，单位是秒 keepalive_timeout 120; #FastCGI相关参数是为了改善网站的性能：减少资源占用，提高访问速度。下面参数看字面意思都能理解。 fastcgi_connect_timeout 300; fastcgi_send_timeout 300; fastcgi_read_timeout 300; fastcgi_buffer_size 64k; fastcgi_buffers 4 64k; fastcgi_busy_buffers_size 128k; fastcgi_temp_file_write_size 128k; #gzip模块设置 gzip on; #开启gzip压缩输出 gzip_min_length 1k; #最小压缩文件大小 gzip_buffers 4 16k; #压缩缓冲区 gzip_http_version 1.0; #压缩版本（默认1.1，前端如果是squid2.5请使用1.0） gzip_comp_level 2; #压缩等级 gzip_types text/plain application/x-javascript text/css application/xml; #压缩类型，默认就已经包含textml，所以下面就不用再写了，写上去也不会有问题，但是会有一个warn。 gzip_vary on; #开启限制IP连接数的时候需要使用 #limit_zone crawler $binary_remote_addr 10m; #负载均衡配置 可设置多个upstream，每个upstream为一组 upstream piao.jd.com { #upstream的负载均衡，weight是权重，可以根据机器配置定义权重。weigth参数表示权值，权值越高被分配到的几率越大。 server 192.168.80.121:80 weight=3; server 192.168.80.122:80 weight=2; server 192.168.80.123:80 weight=3; #nginx的upstream目前支持4种方式的分配 #1、轮询（默认） #每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。 #2、weight #指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。 #例如： #upstream bakend { # server 192.168.0.14 weight=10; # server 192.168.0.15 weight=10; #} #2、ip_hash #每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。 #例如： #upstream bakend { # ip_hash; # server 192.168.0.14:88; # server 192.168.0.15:80; #} #3、fair（第三方） #按后端服务器的响应时间来分配请求，响应时间短的优先分配。 #upstream backend { # server server1; # server server2; # fair; #} #4、url_hash（第三方） #按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存时比较有效。 #例：在upstream中加入hash语句，server语句中不能写入weight等其他的参数，hash_method是使用的hash算法 #upstream backend { # server squid1:3128; # server squid2:3128; # hash $request_uri; # hash_method crc32; #} #tips: #upstream bakend{#定义负载均衡设备的Ip及设备状态}{ # ip_hash; # server 127.0.0.1:9090 down; # server 127.0.0.1:8080 weight=2; # server 127.0.0.1:6060; # server 127.0.0.1:7070 backup; #} #在需要使用负载均衡的server中增加 proxy_pass http://bakend/; #每个设备的状态设置为: #1.down表示单前的server暂时不参与负载 #2.weight为weight越大，负载的权重就越大。 #3.max_fails：允许请求失败的次数默认为1.当超过最大次数时，返回proxy_next_upstream模块定义的错误 #4.fail_timeout:max_fails次失败后，暂停的时间。 #5.backup： 其它所有的非backup机器down或者忙的时候，请求backup机器。所以这台机器压力会最轻。 #nginx支持同时设置多组的负载均衡，用来给不用的server来使用。 #client_body_in_file_only设置为On 可以讲client post过来的数据记录到文件中用来做debug #client_body_temp_path设置记录文件的目录 可以设置最多3层目录 #location对URL进行匹配.可以进行重定向或者进行新的代理 负载均衡 } #虚拟主机的配置 可设置多个Server，做多个站点 server { #监听端口 listen 80; #域名可以有多个，用空格隔开 server_name www.jd.com jd.com; index index.html index.htm index.php; root /data/www/jd; #对******进行负载均衡 location ~ .*.(php|php5)?$ { fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; include fastcgi.conf; } #图片缓存时间设置 location ~ .*.(gif|jpg|jpeg|png|bmp|swf)$ { expires 10d; } #JS和CSS缓存时间设置 location ~ .*.(js|css)?$ { expires 1h; } #日志格式设定 #$remote_addr与$http_x_forwarded_for用以记录客户端的ip地址； #$remote_user：用来记录客户端用户名称； #$time_local： 用来记录访问时间与时区； #$request： 用来记录请求的url与http协议； #$status： 用来记录请求状态；成功是200， #$body_bytes_sent ：记录发送给客户端文件主体内容大小； #$http_referer：用来记录从那个页面链接访问过来的； #$http_user_agent：记录客户浏览器的相关信息； #通常web服务器放在反向代理的后面，这样就不能获取到客户的IP地址了，通过$remote_add拿到的IP地址是反向代理服务器的iP地址。反向代理服务器在转发请求的http头信息中，可以增加x_forwarded_for信息，用以记录原有客户端的IP地址和原来客户端的请求的服务器地址。 log_format access '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" $http_x_forwarded_for'; #定义本虚拟主机的访问日志 access_log /usr/local/nginx/logs/host.access.log main; access_log /usr/local/nginx/logs/host.access.404.log log404; #对 "/" 启用反向代理 ----server_name下转发到后端服务器地址配置 location / { #转发到后端服务器地址配置，要做负载，配置upstream的名称即可 proxy_pass http://upstream_name; #用来定义故障转移策略，当后端服务节点返回 500、 502、 503、504 和执行超时等错误时，自动将请求转发到upstream负载均衡组中的另一台服务器，实现故障转移。 proxy_next_upstream http_500 http_502 http_503 error timeout invalid_header; ##禁止重定向 proxy_redirect off; #proxy_set_header设置由后端的服务器获取用户的主机名或真实IP地址，以及代理者的真实IP地址。 proxy_set_header X-Real-IP $remote_addr; #后端的Web服务器可以通过X-Forwarded-For获取用户真实IP proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; #以下是一些反向代理的配置，可选。 proxy_set_header Host $host; #允许客户端请求的最大单文件字节数 client_max_body_size 10m; #缓冲区代理缓冲用户端请求的最大字节数， #如果把它设置为比较大的数值，例如256k，那么，无论使用firefox还是IE浏览器，来提交任意小于256k的图片，都很正常。如果注释该指令，使用默认的client_body_buffer_size设置，也就是操作系统页面大小的两倍，8k或者16k，问题就出现了。 #无论使用firefox4.0还是IE8.0，提交一个比较大，200k左右的图片，都返回500 Internal Server Error错误 client_body_buffer_size 128k; #表示使nginx阻止HTTP应答代码为400或者更高的应答。 proxy_intercept_errors on; #后端服务器连接的超时时间_发起握手等候响应超时时间 #nginx跟后端服务器连接超时时间(代理连接超时) proxy_connect_timeout 90; #后端服务器数据回传时间(代理发送超时) #后端服务器数据回传时间_就是在规定时间之内后端服务器必须传完所有的数据 proxy_send_timeout 90; #连接成功后，后端服务器响应时间(代理接收超时) #连接成功后_等候后端服务器响应时间_其实已经进入后端的排队之中等候处理（也可以说是后端服务器处理请求的时间） proxy_read_timeout 90; #设置代理服务器（nginx）保存用户头信息的缓冲区大小 #设置从被代理服务器读取的第一部分应答的缓冲区大小，通常情况下这部分应答中包含一个小的应答头，默认情况下这个值的大小为指令proxy_buffers中指定的一个缓冲区的大小，不过可以将其设置为更小 proxy_buffer_size 4k; #proxy_buffers缓冲区，网页平均在32k以下的设置 #设置用于读取应答（来自被代理服务器）的缓冲区数目和大小，默认情况也为分页大小，根据操作系统的不同可能是4k或者8k proxy_buffers 4 32k; #高负荷下缓冲大小（proxy_buffers*2） proxy_busy_buffers_size 64k; #设置在写入proxy_temp_path时数据的大小，预防一个工作进程在传递文件时阻塞太长 #设定缓存文件夹大小，大于这个值，将从upstream服务器传 proxy_temp_file_write_size 64k; } #设定查看Nginx状态的地址 location /NginxStatus { stub_status on; access_log on; auth_basic "NginxStatus"; auth_basic_user_file confpasswd; #htpasswd文件的内容可以用apache提供的htpasswd工具来产生。 } #本地动静分离反向代理配置 #所有jsp的页面均交由tomcat或resin处理 location ~ .(jsp|jspx|do)?$ { proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_pass http://127.0.0.1:8080; } #所有静态文件由nginx直接读取不经过tomcat或resin location ~ .*.(htm|html|gif|jpg|jpeg|png|bmp|swf|ioc|rar|zip|txt|flv|mid|doc|ppt| pdf|xls|mp3|wma)$ { expires 15d; } location ~ .*.(js|css)?$ { expires 1h; } } } ######Nginx配置文件nginx.conf中文详解#####
Nginx由内核和模块组成，其中，内核的设计非常微小和简洁，完成的工作也非常简单，仅仅通过查找配置文件将客户端请求映射到一个location block（location是Nginx配置中的一个指令，用于URL匹配），而在这个location中所配置的每个指令将会启动不同的模块去完成相应的工作。
Nginx的模块从结构上分为核心模块、基础模块和第三方模块：
核心模块：HTTP模块、EVENT模块和MAIL模块
基础模块：HTTP Access模块、HTTP FastCGI模块、HTTP Proxy模块和HTTP Rewrite模块，
第三方模块：HTTP Upstream Request Hash模块、Notice模块和HTTP Access Key模块。
用户根据自己的需要开发的模块都属于第三方模块。正是有了这么多模块的支撑，Nginx的功能才会如此强大。
Nginx的模块从功能上分为如下三类。
Handlers（处理器模块）。此类模块直接处理请求，并进行输出内容和修改headers信息等操作。Handlers处理器模块一般只能有一个。
Filters （过滤器模块）。此类模块主要对其他处理器模块输出的内容进行修改操作，最后由Nginx输出。
Proxies （代理类模块）。此类模块是Nginx的HTTP Upstream之类的模块，这些模块主要与后端一些服务比如FastCGI等进行交互，实现服务代理和负载均衡等功能。
Nginx本身做的工作实际很少，当它接到一个HTTP请求时，它仅仅是通过查找配置文件将此次请求映射到一个location block，而此location中所配置的各个指令则会启动不同的模块去完成工作，因此模块可以看做Nginx真正的劳动工作者。通常一个location中的指令会涉及一个handler模块和多个filter模块（当然，多个location可以复用同一个模块）。handler模块负责处理请求，完成响应内容的生成，而filter模块对响应内容进行处理。
Nginx的模块直接被编译进Nginx，因此属于静态编译方式。启动Nginx后，Nginx的模块被自动加载，不像Apache，首先将模块编译为一个so文件，然后在配置文件中指定是否进行加载。在解析配置文件时，Nginx的每个模块都有可能去处理某个请求，但是同一个处理请求只能由一个模块来完成。
我们知道,Linux提供了多种进程间传递消息的方式，比如共享内存、套接字、管道、消息队列、信号等，每种方式都各有特点，各有优缺点。其中Nginx主要使用了其中的三种方式:
套接字（匿名套接字对）共享内存信号 本文主要结合代码讲一下前两种方式，匿名套接字对和共享内存在Nginx中的使用。概述
Nginx中的channel通信，本质上是多个进程之间,利用匿名套接字(socketpair)对来进行通信。 我们知道,socketpair可以创建出一对套接字,在这两个套接字的任何一个上面进行写操作,在另一个套接字上就可以相应的进行读操作,而且这个管道是全双工的。 那么,当父进程在调用了socketpair创建出一对匿名套接字对(A1,B1)后,fork出一个子进程,那么此时子进程也继承了这一对套接字对(A2,B2)。在这个基础上,父子进程即可进行通信了。例如,父进程对A1进行写操作,子进程可通过B2进行相应的读操作;子进程对B2进行写操作,父进程可以通过A1来进行相应的读操作等等。 我们假设,父进程依次fork了N个子进程,在每次fork之前,均如前所述调用了socketpair建立起一个匿名套接字对,这样,父进程与各个子进程之间即可通过各自的套接字对来进行通信。 但是各子进程之间能否使用匿名套接字对来进行通信呢？ 我们假设父进程A中,它与子进程B之间的匿名套接字对为AB[2],它与子进程C之间的匿名套接字对为AC[2]。且进程B在进程C之前被fork出来。 对进程B而言，当它被fork出来后，它就继承了父进程创建的套接字对,命名为BA[2],这样父进程通过操作AB[2]，子进程B通过操作BA[2],即可实现父子进程之间的通信。 对进程C而言,当它被fork出来后，他就继承了父进程穿件的套接字对，命名为CA[2],这样父进程通过操作AC[2]，子进程C通过操作CA[2]，即可实现父子进程之间的通信。 但B和C有一点不同。由于B进程在C之前被fork，B进程无法从父进程中继承到父进程与C进程之间的匿名套接字对,而C进程在后面被fork出来，它却从父进程处继承到了父进程与子进程B之间的匿名套接字对。 这样，之后被fork出来的进程C,可以通过它从父进程那里继承到的与B进程相关联的匿名套接字对来向进程B发送消息，但进程B却无法向进程C发送消息。 当子进程数量比较多时，就会造成这样的情况：即后面的进程拥有前面每一个子进程的一个匿名套接字，但前面的进程则没有后面任何一个子进程的匿名套接字。 那么这个问题该如何解决呢？这就涉及到进程间传递文件描述符这个话题了。可以参考这里:进程之间传递文件描述符。一个子进程被fork出来后，它可以依次向它之前被fork出来的所有子进程传递自己的描述符（匿名套接字对中的一个)。 通过这种机制,子进程之间也可以进行通信了。 Nginx中也就是这么做的。
Nginx中的具体实现
在ngx_process.c中，定义了一个全局的数组ngx_processes:ngx_process_t ngx_processes\[NGX\_MAX\_PROCESSES\]; 其中,ngx_process_t类型定义为:
typedef struct { ngx_pid_t pid; int status; ngx_socket_t channel\[2\]; ngx_spawn_proc_pt proc; void *data; char *name; unsigned respawn:1; unsigned just_spawn:1; unsigned detached:1; unsigned exiting:1; unsigned exited:1; } ngx_process_t;
在这里,我们只关心成员channel成员，这个两元素的数组即用来存放一个匿名套接字对。
我们假设程序运行后，有1个master进程和4个worker进程。那么，对这5个进程而言，每个进程都有一个4元素的数组ngx_processes[4]，数组中每个元素都是一个ngx_process_t类型的结构体，包含了相应的某个worker进程的相关信息。我们这里关心的是每个结构体的channel数组成员。
绘制成表如下:
上表的每一列表示每个进程的ngx_processes数组的各个元素的channel成员。
其中，master进程列中的每一个元素，表示master进程与对应的每个worker进程之间的匿名套接字对。
而每一个worker进程列中的每一个元素，表示该worker进程与对应的每个worker进程之间的匿名套接字对。当然这只是一个粗略的说法，与真实情况并不完全相符，还有很多细节需要进一步阐述。
我们直接借助《深入剖析Nginx》，直接看下图的实例:
再次感谢《深入剖析Nginx》的作者高群凯，觉得在这里我没法表达的比他更好了。所以下面会引用很多该书中的内容。
在上表中，每一个单元格的内容分别表示channel[ 0 ]和channel[ 1 ]的值，-1表示这之前是描述符，但在之后被主动close()掉了，0表示这一直都无对应的描述符，其他数字表示对应的描述符值。
每一列数据都表示该列所对应进程与其他进程进行通信的描述符，如果当前列所对应进程为父进程，那么它与其它进程进行通信的描述符都为channel[ 0 ](其实channel[ 1 ]也可以)；如果当前列所对应的进程为子进程，那么它与父进程进行通信的描述符为channel[ 1 ]（注：这里书中说的太简略，应该为如果当前列所对应的进程为子进程，那么它与父进程进行通信的描述符为该进程的ngx_processes数组中，与本进程对应的元素中的channel[ 1 ]，在图中即为标粗的对角线部分，即[-1,7],[-1,9],[-1,11],[-1,13]这四对），与其它子进程进行通信的描述符都为本进程的ngx_processes数组中与该其它进程对应元素的channel[ 0 ]。
比如，[3,7]单元格表示，如果父进程向worker0发送消息，需要使用channel[ 0 ]，即描述符3，实际上channel[ 1 ]也可以，它的channel[ 1 ]为7，没有被close()关闭掉，但一直也没有被使用，所以没有影响，不过按道理应该关闭才是。
再比如，[-1,7]单元格表示如果worker0向master进程发送消息，需要使用channel[ 1 ]，即描述符7，它的channel[ 0 ]为-1，表示已经close()关闭掉了（Nginx某些地方调用close()时并没有设置对应变量为-1，这里只是为了更好的说明，将已经close()掉的描述符全部标记为-1）。
越是后生成的worker进程，其ngx_processes数组的元素中，channel[ 0 ]与父进程对应的ngx_processes数组的元素中的channel[ 0 ]值相同的越多，因为基本都是继承而来，但前面生成的worker进程，其channel[ 0 ]是通过进程间调用sendmsg传递获得的，所以与父进程对应的channel[ 0 ]不一定相等。比如，如果worker0向worker3发送消息，需要使用worker0进程的ngx_processes[ 3 ]元素的channel[ 0 ],即描述符10，而对应master进程的ngx_processes[ 3 ]元素的channel[ 0 ]却是12。虽然它们在各自进程里表现为不同的整型数字，但在内核里表示同一个描述符结构，即不管是worker0往描述符10写数据，还是master往描述符12写数据，worker3都能通过描述符13正确读取到这些数据，至于worker3怎么识别它读到的数据是来自worker0，还是master，就得靠其他收到的数据特征，比如pid，来做标记区分。
关于上段讲的，一个子进程如何区分接收到的数据是来自哪一个进程，我们可以看一下Nginx-1.6.2中的一段代码:
最后，就目前Nginx代码来看，子进程并没有往父进程发送任何消息，子进程之间也没有相互通信的逻辑。也许是因为Nginx有其他一些更好的进程通信方式，比如共享内存等，所以这种channel通信目前仅作为父进程往子进程发送消息使用。但由于有这个架构在，可以很轻松使用channel机制来完成各进程间的通信任务。
概述
共享内存是Linux下提供的最基本的进程间通信方法，它通过mmap或者shmget系统调用在内存中创建了一块连续的线性地址空间，而通过munmap或者shmdt系统调用可以释放这块内存。使用共享内存的好处是当多个进程使用同一块共享内存时，在任何一个进程修改了共享内存中的内容后，其他进程通过访问这段共享内存都能够得到修改后的内容。 共享内存可以说是最有用的进程间通信方式，也是最快的IPC形式。两个不同进程A、B共享内存的意思是，同一块物理内存被映射到进程A、B各自的进程地址空间。进程A可以即时看到进程B对共享内存中数据的更新，反之亦然。由于多个进程共享同一块内存区域，必然需要某种同步机制，互斥锁和信号量都可以。 采用共享内存通信的一个显而易见的好处是效率高，因为进程可以直接读写内存，而不需要任何数据的拷贝。对于像管道和消息队列等通信方式，则需要在内核和用户空间进行四次的数据拷贝，而共享内存则只拷贝两次数据：一次从输入文件到共享内存区，另一次从共享内存区到输出文件。实际上，进程之间在共享内存时，并不总是读写少量数据后就解除映射，有新的通信时，再重新建立共享内存区域。而是保持共享区域，直到通信完毕为止，这样，数据内容一直保存在共享内存中，并没有写回文件。共享内存中的内容往往是在解除映射时才写回文件的。因此，采用共享内存的通信方式效率是非常高的。 Linux中，共享内存可以通过两个系统系统调用来获得，mmap和shmget，分别属于不同的标准，这不在本文的关注范围之内。mmap语义上比shmget更通用，因为它最一般的做法，是将一个打开的实体文件，映射到一段连续的内存中，各个进程可以根据各自的权限对该段内存进行相应的读写操作，其他进程则可以看到其他进程写入的结果。而shmget在语义上相当于是匿名的mmap，即不关注实体文件，直接在内存中开辟这块共享区域，mmap通过设置调用时的参数，也可达到这种效果，一种方法是映射/dev/zero设备,另一种是使用MAP_ANON选项。至于mmap和shmget的效率，跟不同的内核实现相关，不在本文关注范围内。 除了上面的简单描述外，本文不打算仔细介绍mmap和shmget的使用。有如下相关资料可以参考:Linux环境进程间通信（五）: 共享内存（上）Linux环境进程间通信（五）: 共享内存（下） APUE,14.8,15.9
Nginx中的实现
那么，在Nginx中，到底是选用mmap映射到/dev/null，还是使用MAP_ANON选项调用mmap，或者是使用shmget呢？看相关实现的代码就会一目了然: 上面的代码即是Nginx源代码中的src/os/unix/ngx_shemem.c的全部内容。可见，整个文件只是为了提供两个接口：ngx_shm_alloc和ngx_shm_free。而这两个接口的实现，按如下逻辑来决定:
如果当前系统的mmap系统调用支持MAP_ANON选项，则使用带MAP_ANON选项的mmap。 如果1不满足，则如果当前系统mmap系统调用支持映射/dev/zero设备，则使用mmap映射/dev/zero的方式来实现。 如果上面1和2都不满足，且如果当前系统支持shmget系统调用的话，则使用该系统调用来实现。 看到这里，也许大家就有疑问了，如果当前3个条件都不满足怎么办，那就没辙了，ngx_shm_alloc接口没有相应的定义，只能在链接的时候就不成功了。
另外，关于上面三种情况的判断，都是通过相应的宏是否定义来进行的，而相应的宏的定义，是在auto/unix脚本中进行的，该脚本会写一端测试程序来判断相应的系统调用是否支持，如果支持，则在configure后自动生成的objs/ngx_auto_config.h文件中定义对应的宏。
前面讲Nginx中的channel机制时提到，Nginx虽然提供了这种机制，但目前很少用到，而共享内存却相对用的比较多了。例如，为了统计Nginx总体的http请求处理情况，需要跨越多个worker来计算，Nginx自带的http模块ngx_http_stub_status_module即主要依赖共享内存的方式。
Ref:http://pureage.info/2015/03/28/ipc-of-nginx.html
作者：jiangmo 链接：https://www.jianshu.com/p/80259e857f56 来源：简书 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
