nginx（一） nginx详解
nginx是一个被广泛使用的集群架构组件，我们有必要对它有足够的了解。下面将先认识nginx：包括应用场景、nginx基本架构、功能特性、并发模型以及配置说明，最后我们再总结下，为什么选择nginx的原因。
1、nginx应用
nginx （engine x）是一个可以作为HTTP WEB服务器、反向代理服务器、邮件代理服务器和一个通用的TCP / UDP代理服务器（1.9.0版本后）的多功能架构组件，同时也可以提供一定的缓存服务功能。
nginx应用比较多的场景是WEB服务器和反向代理服务器，这两个场景的相关配置后面的文章我们会分别操作配置，这里先来认识下：
1、WEB服务器：这是应用比较多的场景，配置虚拟主机提供HTTP WEB服务。可以先通过动态/静态内容分离，而后为静态内容（html/css/js/图片等）提供HTTP访问功能；而动态内容可以整合代理模块，代理给上游服务器，来支持对外部程序的直接调用或者解析，如FastCGI支持PHP。
2、反向代理服务器：这是应用非常多的场景，为后端服务器代理。接收客户端请求，根据负载均衡策略转发给后端多个上游服务器处理；然后再等待后端服务器返回请求响应，接收到后再返回给请求的客户端。
2、nginx基本架构
1、一个master进程生成多个worker子进程（每个进程只有一个线程），一个worker响应多个用户请求；
2、非阻塞、IO复用、事件驱动：select，poll， epoll， kqueue，/dev/poll；
3、支持sendfile，sendfile64；
4、支持文件AIO（异步I/O）；
5、支持mmap；
6、灵活的文件配置；
7、占用内存小：10,000个非活动HTTP保持连接占用大约2.5M内存。
3、nginx功能特性
3-1、基本功能
实现与服务静态文件（静态资源的web服务器），能缓存打开的文件描述符；
反向代理服务器，缓存、负载均衡、健康状态检测；
支持FastCGI；
模块化机制，非DSO机制，支持多种过滤器gzip，SSI和图像的模块完成图形大小调整等；
支持SSL；
3-2、扩展功能
基于名称和IP做虚拟主机；
支持keeplive；
支持平滑配置更新或程序版本升级；
定制访问日志，支持使用日志缓存以提高性能；
支持URL rewrite；
支持路径别名；
支持基于IP及用户的认证；
支持速率限制，并发数限制等；
4、nginx并发模型
如前图，一个master进程生成多个worker子进程（每个进程只有一个线程），一个worker响应多个用户请求。如果单进程启动：仅有一个进程，既充当master进程的角色，也充当worker进程的角色。
4-1、master进程
充当整个进程组与用户的交互接口（接收来自外界的信号，向各worker进程发送信号），同时监控worker进程的运行状态。
它不需要处理网络事件，不负责业务的执行，只会通过管理worker进程来实现重启服务、平滑升级、更换日志文件、配置文件实时生效等功能。
4-2、worker进程
主要任务是处理基本的网络事件，完成具体的任务逻辑。多个worker进程之间是对等的，互相独立的。
worker进程主要关注点是与客户端或后端服务器（此时nginx作为中间代理）之间的数据可读/可写等I/O交互事件，所以工作进程的阻塞点是在像select()、epoll_wait()等这样的I/O多路复用函数调用处，以等待发生数据可读/写事件。当然也可能被新收到的进程信号中断。
worker进程个数：
如果负载以CPU密集型应用为主，一般会设置与机器cpu核数一致或少一个（用来处理用户等其他任务）；
如果负载以IO密集型为主，如响应大量内容给客户端，则worker数应该为CPU个数的1.5或2倍。
因为更多的worker数，只会导致进程来竞争cpu资源了，从而带来不必要的上下文切换。而且，nginx为了更好的利用多核特性，具有cpu绑定选项，我们可以将某一个进程绑定在某一个核上，这样就不会因为进程的切换带来cache的失效。
更具体的可以根据公式：Nthread = Ncpu*Ucpu*(1+W/C)，Ncpu是cpu的个数，Ucpu是cpu的使用率，W为等待时间，C为计算时间。这时需要通过监控工具来获取相应数据来计算。
最后，再以监控工具数据为准进行微调。
4-3、并发处理
A、在master进程里面，先创建socket，并bind、listen在80端口（所以master进程需要root权限）；
B、然后再fork出多个worker进程，这样每个worker进程都可以去accept这个socket（会产生惊群问题）， 或者使用锁机制，让抢到锁的一个worker进程去accept这个socket，注意这里一般使用select/poll/epoll机制来解决accept阻塞问题；
C、当一个新连接进来后，而只有抢到锁的一个进程可以accept这个连接进行处理（也是放入epoll中）；
D、抢到锁的worker进程accept到新连接后，会立即释放锁；然后所有worker进程再次参与抢锁，这样就回到了第二步，进行循环处理并发连接；
4-4、惊群问题
A、生产原因：像上面第二步，多个worker进程等待同一个socket的连接事件，当这个事件发生时，这些进程被同时唤醒，就是惊群。
注意，在linux2.6内核上，accept系统调用已经不存在惊群，但用epoll机制来解决accept阻塞问题，epoll_wait会有惊群问题（新增 EPOLLEXCLUSIVE 选项解决了）。
B、导致后果：许多worker进程被内核重新调度唤醒，只有一个进程可以accept这个连接进行处理，其他余者皆失败，导致性能浪费。
C、nginx解决方案：使用锁机制，让抢到锁的一个worker进程去accept（epoll_wait）这个socket；如果操作系统支持原子整型，才会使用共享内存实现原子上锁，否则使用文件上锁。
5、Nginx配置说明
5-1、配置文件区域说明
nginx主要配置文件nginx.conf，里面主要包括以下几个配置区域，如下表：
| 配置区域 | 说明 |
| main块 | 配置影响nginx全局的指令。一般有运行nginx服务器的用户组，nginx进程pid存放路径，日志存放路径，配置文件引入，允许生成worker process数等。 |
| events块 | 配置影响nginx服务器或与用户的网络连接。有每个进程的最大连接数，选取哪种事件驱动模型处理连接请求，是否允许同时接受多个网路连接，开启多个网络连接序列化等。 |
| http块 | 可以嵌套多个server，配置代理，缓存，日志定义等绝大多数功能和第三方模块的配置。如文件引入，mime-type定义，日志自定义，是否使用sendfile传输文件，连接超时时间，单连接请求数等。 |
| upstream块 | 配置HTTP负载均衡器分配流量到几个应用程序服务器。 |
| server块 | 配置虚拟主机的相关参数，一个http中可以有多个server。 |
| location块 | 配置请求的路由，以及允许根据用户请求的URI来匹配指定的各location以进行访问配置；匹配到时，将被location块中的配置所处理。 |
nginx文件结构如下：
5-2、Nginx核心功能配置
nginx核心功能配置主要是main和events的顶层全局配置，都是配置nginx核心模块（ngx_core_module），管理服务器级别的行为。下表包含是大部分常用的配置选项，更多配置请参考官方文档：http://nginx.org/en/docs/ngx_core_module.html
| 配置类别 | 配置选项 | 上下文 | 语法 | 默认值 | 功能描述 |
| 基本配置 | user | main | user username [groupname] | nobody | 以那个用户身份运行,以在configure指定的用户为准 |
| pid | main | pid /path/to/pid_filename | nginx.pid | 指定nginx的pid文件 | |
| worker_rlimit_nofile | main | 受linux内核文件描述符数量限制 | 指定一个worker进程所能够打开的句柄数。因为Linux对每个进程所能打开的文件描述数量是有限制的，默认一般是1024个，可通过ulimit -n FILECNT或/etc/securit/limits.conf配置修改linux默认能打开的文件句柄数限制。建议值为：系统最大数量/进程数。但进程间工作量并不是平均分配的，所以可以设置在大一些。推荐值为：655350。 | ||
| 优化性能相关配置 | worker_procrsses | main | worker_processes number | auto; | 1 | work进程的个数.如果负载以CPU密集型应用为主，一般会设置与机器cpu核数一致或少一个（用来处理用户等其他任务），如果负载以IO密集型为主，如响应大量内容给客户端，则worker数应该为CPU个数的1.5或2倍。因为更多的worker数，只会导致进程来竞争cpu资源了，从而带来不必要的上下文切换。而且，nginx为了更好的利用多核特性，具有cpu绑定选项，我们可以将某一个进程绑定在某一个核上，这样就不会因为进程的切换带来cache的失效。 |
| worker_cpu_affinity | main | worker_cpu_affinity cpumask ...; | 无，不绑定 | 将工作进程绑定到特定的CPU上，减少CPU在进程之间切换的开销。用二进制bit位表示进程绑定在哪个CPU内核。如4工作进程4内核：worker_processes 4; worker_cpu_affinity 0001 0010 0100 1000; 2工作进程4内核： worker_processes 2; worker_cpu_affinity 0101 1010; | |
| worker_priority | main | worker_priority number; | 0 | 工作进程调度优先级，-20到19之间的值，值越小越优先调用。如果系统同时运行多个任务，你可能需要提高nginx的工作进程的优先级 | |
| timer_resolution | main | timer_resolution interval; | 无 | 每次内核事件调用返回时，都会使用gettimeday（）来更新nginx缓存时钟；timer_resolution用于定义每隔多久才会由gettimeday（）更新一次缓存时钟；x86-64系统上，gettimeday()代价已经很小，可以忽略此配置 | |
| ssl_engine | main | ssl_engine device; | 无 | 在存在ssl硬件加速器的服务器上，指定所使用的ssl硬件加速设备。由于https链接所消耗的资源比http大得多，可能要多消耗5、6倍，最好有专门处理ssl的硬件设备 | |
| 事件相关配置 | worker_commections | events | worker_connections number; | 512 | 每个worker能够并发响应的最大请求数。系统每处理一个请求就要消耗一个套接字文件，如果为代理服务器的话，worker_rlimit_nofile=worker_commections*2 |
| use | events | use method; | 无，自动选择 | 指定使用哪种模型（select/poll/epoll）,建议让nginx自动选择,linux内核2.6以上一般能使用epoll，提高性能。 | |
| accept_mutex | events | accept_mutex on | off; | Off(1.11.3版本前默认on) | 是否打开nginx的accept锁；此锁能够让多个worker进行轮流地、序列化地与新的客户端建立连接；而通常当一个worker进程的负载达到其上限的7/8，master就尽可能不将请求调度至worker. 1.11.3版本epoll支持EPOLLEXCLUSIVE 标记，不再有惊群问题 。 | |
| accept_mutex_delay | events | accept_mutex_delay time; | 500ms | 使用accept锁以后，只有一个worker能取得锁，一个worker进程为取得accept锁的等待时长，即用户建立等待的时间，如果某worker进程在某次试图取得锁时失败了，至少要等待#ms才能在一次请求锁 | |
| multi_accept | events | multi_accept on | off; | off | 是否允许一次性地响应多个用户请求 | |
| 调试、定位问题配置 | daemon | main | daemon on | off; | on | nginx是否以守护进程运行，是否让nignx运行于后台；调试时应该为off，使得所有信息直接输出在控制台 |
| master_process | main | master_process on | off; | on | 是否以master/worker模式运行nginx，默认为on，调试时可以设置为off以方便追踪 | |
| error_log | main, http, mail, stream, server, location | error_log file [level]; | error_log logs/error.log error; | 配置错误日志文件的路径和日志级别。日志级别有debug, info, notice, warn, error, crit, alert和emerg几种。调试时可以使用debug级别，但要求在编译时必须使用--with-debug启用debug功能，默认通常为error级别. |
5-3、Nginx HTTP核心配置
http功能核心配置主要是http块、server块和location块的配置，包括HTTP核心模块（ngx_http_core_module）和一些扩展模块（如ngx_stream_ssl_module），提供管理WEB服务器级别的行为。
必须使用虚拟机来配置站点，每个虚拟主机使用一个server{}段来配置，非虚拟主机的配置和公共选项，需要定义在server之外，http之内。
下表包含是大部分常用的配置选项，更多配置请参考官方文档：http://nginx.org/en/docs/
| 配置类别 | 配置选项/模块 | 上下文 | 语法 | 默认值 | 功能描述 |
| 基本配置 | http | main | http { ... } | 无 | 提供HTTP服务器配置上下文 |
| server | http | server { ... } | 无 | HTTP服务器的核心配置，定义一个虚拟主机：nginx支持使用基于主机名或IP的虚拟主机 | |
| listen | server | listen address[:port] listen prot listen unix:socket | listen *:80 | *:8000 | 配置虚拟主机监听的IP地址和端口，默认监听本机IP地址和80或8000端口。如果只设置了IP没设端口，默认使用80端口。如果只设置了端口，没设置IP默认使用本机IP。 后面可以指定一些参数： default_server:定义此server为http中默认的server；如果所有的server中任何一个listen使用此参数，那么第一个server即为默认server； rcvbuf=SIZE：接收缓存大小； sndbuf=SIZE: 发送缓存大小； ssl：https server：必须以ssl连接； | |
| server_name | server | server_name name ...; | "" | 配置虚拟主机的域名，可以指定多个，用空格分隔。默认为空。 名称可以使用通配符和正则表达式（通常以~开头）：当nginx收到一个请求时，会取出其首部的server的值，而后跟众server_name进行比较：比较方式 (1) 先做精确匹配，如www.tjiyu.com (2) 左侧通配符匹配，如*tjiyu.com (3) 右侧通配符匹配，如www.* (4) 正则表达式匹配 | |
| server_name_hash_bucket_size | server | server_names_hash_bucket_size size; | 32|64|128 | 为了实现快速主机查找，nginx使用hash表来保存主机名。 默认值取决于处理器缓存线的大小。 | |
| location | server, location | location [ = | ~ | ~* | ^~ ] uri { ... } location @name { ... } | 无 | 允许根据用户请求的URI来匹配指定的各location以进行访问配置；匹配到时，将被location块中的配置所处理。 =：精确匹配； ~：正则表达式模式匹配，匹配时区分字符大小写； ~*：正则表达式模式匹配，匹配时忽略字符大小写； ^~:只需要前半部分与uri匹配即可，不检查正则表达式； 匹配优先级： 字符字面量最精确匹配、正则表达式检索（由多个时，由第一个匹配到的所处理），按字符字面量。 | |
| 资源路径定义配置 | root | http, server, location, if in location | root path; | root html; | 设置web资源路径，用于指定请求的根文档目录，从根开始匹配。 如root /html/image/，请求"/tjiyu.gif"对应的文件为"/html/image/tjiyu.gif" |
| alias | location | alias path; | 无 | 指定路径别名，只能用于location中，从最后一个/开始匹配。 如location /i/ { alias /data/w3/images/; } 请求"/i/top.gif", 实际文件"/data/w3/images/top.gif" | |
| Index | http, server, location | index file ...; | index index.html; | ngx_http_index_module. 定义默认页面，可以跟多个值。自左向右匹配。 | |
| error_page | http, server, location, if in location | error_page code ... [=[response]] uri; | 无 | ngx_http_core_module 当对于某个请求发回错误时，如果匹配上了error_page指令中设定的code，则从定向至新的URI中，错误重定向. 如 error_page 500 502 503 504 /50x.html; 也可以改变返回码。 如error_page 404 =200 /404.html; | |
| try_files | server, location | try_files file ... uri; try_files file ... =code; | 无 | 自左向右尝试读取有path所指定路径，在第一找到即停止并返回，如果所有path均不存在，则返回最后一个uri或者code. 如try_files $uri $uri/index.html $uri.html =404; | |
| 网络连接相关设置 | keepalive_timeout | http, server, location | keepalive_timeout timeout [header_timeout]; | 75s | 保持连接的超时时长，默认为75s。 降低每个连接的alive时间可在一定程度上提高可响应连接数量，所以一般可适当降低此值 |
| keepalive_requests | http, server, location | keepalive_requests number; | 100 | 在一次长连接上允许承载的最大请求数。 | |
| keepalive_disable | http, server, location | keepalive_disable none | browser ...; | msie6（ie6无法长连接） | 对指定的浏览器禁止使用长连接。 | |
| tcp_nodelay | http, server, location | tcp_nodelay on | off; | on | 这里指ngx_http_core_module模块的选项。 对keepalive连接是否使用tcp_nodelay选项 启动配置，会在数据包达到一定大小后再发送数据。这样会减少网络通信次数，降低阻塞概率，但也会影响响应及时性。比较适合于文件下载这类的大数据通信场景。 | |
| client_header_timeout | http, server | client_header_timeout time; | 60s | 读取http请求首部的超时时长。 如果客户端在此时间内未传输整个头，则会向客户端返回408（请求超时）错误。 | |
| client_body_timeout | http, server, location | client_body_timeout time; | 60s | 读取http请求包体的超时时间。 | |
| send_timeout | http, server, location | send_timeout time; | 60s | 发送响应的超时时长。 超时后连接将关闭。 | |
| 对客户端请求的限制配置 | limit_except | location | limit_except method ... { ... } | on | 指定范围之外的其他方法的访问控制。 方法有：GET, HEAD, POST, PUT, DELETE, MKCOL, COPY, MOVE, OPTIONS, PROPFIND, PROPPATCH, LOCK, UNLOCK, or PATCH. 如只允许GET访问： limit_except GET { allow 192.168.1.0/32; deny all; } |
| client_max_body_size | http, server, location | client_max_body_size size; | 1m | http请求包体的最大值，常用于限定客户端所能够请求的最大包体，根据请求首部中的Content-Length来检查，以避免无用的传输。 | |
| limit_rate | http, server, location, if in location | limit_rate rate; | 0 | 限制客户端每秒传输的字节数，默认为0，表示没有限制。 | |
| limit_rate_after | http, server, location, if in location | limit_rate_after size; | 0 | nginx向客户端发送响应报文时，如果时长超过了此处指定的时长，则后续的发送过程开始限速（下载站点常用）。 配置上面的limit_rate使用。 | |
| 对客户端请求的特殊处理 | ignore_invalid_headers | http, server | ignore_invalid_headers on | off; | on | 是否忽略不合法的http首部，默认为on，off意味着请求首部中出现不合规的首部将拒绝响应。 |
| log_not_found | http, server, location | log_not_found on | off; | on | 用户访问的文件不存在时，是否将其记录到错误日志中。 | |
| resolver | http, server, location | resolver address ... [valid=time] [ipv6=on|off]; | 无 | 这里指ngx_http_core_module模块选项、 指定nginx使用的dns服务器地址。 valid = 30s，整缓存时间设置。在1.1.9版之前，不可能调整缓存时间，而nginx总是缓存答案5分钟的时间。 | |
| resolver_timeout | http, server, location | resolver_timeout time; | 30s | 指定DNS解析超时时长。 | |
| server_tokens | http, server, location | server_tokens on | off | string; | on | 是否在错误页面中显示和"响应头字段中发出nginx的版本号。 从版本1.9.13开始，可以使用带有变量的字符串显式设置。 空字符串禁用。 | |
| 文件操作的优化 | sendfile | http, server, location, if in location | sendfile on | off; | off | 是否启用sendfile内核复制模式功能。 作为静态服务器可以提高最大的IO访问速度。传统的文件读写采用read和write方式，流程为：硬盘 >> kernel buffer >> user buffer>> kernel socket buffer >>协议栈，采用sendfile文件读写的流程为：硬盘 >> kernel buffer (快速拷贝到kernelsocket buffer) >>协议栈，很明显sendfile这个系统调用减少了内核到用户模式之间的切换和数据拷贝次数，直接从内核缓存的数据拷贝到协议栈，提高了很大的效率。 |
| aio | http, server, location | aio on | off | threads[=pool]; | off | 是否启用异步文件IO功能。 Linux从内核版本2.6.22开始支持，有必要启用directio，否则读取将阻塞。 directio只能用于读取在512字节边界（或XFS为4K）上对齐的块。文件结束未对齐将在阻塞模式下读取。 当在Linux上同时启用AIO和sendfile功能时，AIO用于大于或等于directio指令中指定大小的文件，而小于或禁用directio时则用sendfile。 location /video/ { sendfile on; aio on; directio 8m; } | |
| open_file_cache | http, server, location | open_file_cache off; open_file_cache max=N [inactive=time]; | off | 是否打开文件缓存功能。 max：用于缓存条目的最大值，允许打开的缓存条目最大数，当满两类以后将根据LRU（最小最少连接数）算法进行置换 inactive：某缓存条目在指定时长内没有被访问过时，将自动被删除，即缓存有效期，通常默认为60s。 缓存的信息包括： 文件句柄、文件大小和上次修改时间； 已经打开的目录结构； 没有找到或没有访问权限的信息等。 建议值：max=655350（和worker_rlimit_nofile参数一致） inactive=20s; | |
| open_file_cache_errors | http, server, location | open_file_cache_errors on | off; | off | 是否缓存文件找不到或没有权限访问等相关信息。 | |
| open_file_cache_valid | http, server, location | open_file_cache_valid time; | 60s | 多长时间检查一次缓存中的条目是否超出非活动时长。 建议值：小于等于open_file_cache inactive | |
| open_file_cache_min_use | http, server, location | open_file_cache_min_uses number; | 1 | 在open_file_cache inactive指定的时长内被访问超过此处指定的次数时，才不会被删除（删除低命中率的缓存）。 | |
| Gzip压缩相关配置 | gzip | http, server, location, if in location | gzip on | off; | off | 开启内容压缩，可以有效降低客户端的访问流量和网络带宽 |
| gzip_min_length | http, server, location | gzip_min_length length; | 20k | 内容超过最少长度后才开启压缩，因为太短的内容压缩效果不佳，且压缩过程还会浪费系统资源。这个压缩长度会作为http响应头Content-Length字段返回给客户端。 建议值：64 | |
| gzip_comp_level | http, server, location | gzip_comp_level 1~9; | 1 | 压缩级别，默认值为1。范围为1～9级，压缩级别越高压缩率越高，但对系统性能要求越高。 建议值：4 | |
| gzip_types | http, server, location | gzip_types mime-type …; | text/html | 压缩内容类型，默认为text/html;。只压缩html文本，一般我们都会压缩js、css、json之类的，可以把这些常见的文本数据都配上。如：text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript; |
5-4、配置变量
Nginx配置文件支持使用变量，可以使用内置变量或自定义变量。用户自定义变量语法：set var_name value；http核心模块的内置变量（http://nginx.org/en/docs/varindex.html），主要有如下：
5-5、if判断语句
if是URL地址重写ngx_http_rewrite_module模块中的选项。
在location中使用if语句可以实现条件判断，其通常有一个return语句，且一般与有着last或break标记的rewrite规则一同使用。但其也可以按需要使用在多种场景下，需要注意的是，不当的使用可能会导致不可预料的后果。if语句中的判断条件匹配用法如下：
比如：
if ($request_method == "PUT") { #判断请求方法
}
if ($request_uri ~ "\.(jpg|gif|jpeg|png)$"){#判断URL是否是以这些结尾的图片
}
6、nginx命令行参数
nginx 仅有数个命令行参数，完全通过配置文件来配置。通过"nginx –h"可以查看，如下：
常用选项：
注意，下面安装后我们为nginx提供了一个SysV init服务脚本，就是基于这些命令实现的。
7、为什么选择使用nginx
前面讲了那么多，我们最后来总结下，选择nginx的理由：
7-1、高并发性能的并发模型：性能好、占用内存少、稳定
前面说过，nginx的并发模型中最好设置worker进程与CPU核心数量差不多，而一个worker进程可以处理多个请求，比apache一个进程/一个线程响应响应一个请求的并发模型，可以大大减少进程/线程数量，减少重复的数据，所以内存使用效率较高，占用内存资源少，同时减少CPU调度和上下文切换次数，所以nginx要比apache更"轻量"，且性能更好；
一个worker进程绑定一个CPU核心，更是可以让nginx充分发挥CPU的计算能力来处理请求。
使用IO复用机制避免阻塞，可以处理更多的任务；
多个worker进程互不影响，不像多线程模型，一个线程出问题可能使整个进程内其他线程都崩溃，所以nginx稳定，健壮性好。
7-2、高扩展性
Nginx的模块化设计极具扩展性，它完全是由多个不同功能、不同层次、不同类型且耦合度极低的模块组成。因此，当对某一个模块修复Bug或进行升级时，可以专注于模块自身，无须在意其他。
这种低耦合度的优秀设计，造就了Nginx庞大的第三方模块，当然，公开的第三方模块也如官方发布的模块一样容易使用。
7-3、功能强大，应用前景广阔
Nginx提供大量的功能模块，支持诸多特性，应用场景多，且现今（2016）在WEB服务器应用中占有27.80%份额。
作为 Web 服务器：相比 Apache，Nginx 使用更少的资源，支持更多的并发连接，体现更高的效率，能够支持高达50000个并发连接数的响应。
作为负载均衡服务器：Nginx既可以在内部直接支持 Rails 和 PHP，也可以支持作为 HTTP代理服务器 对外进行服务。Nginx用C编写, 不论是系统资源开销还是 CPU 使用效率都比Perlbal要好的多。
还可作为邮件代理服务器、缓存服务器。
7-4、配置/操作简便
Nginx安装非常的简单，配置文件非常简洁（还能够支持perl语法），Bugs非常少的服务器: Nginx 启动特别容易，并且几乎可以做到7*24不间断运行，即使运行数个月也不需要重新启动。你还能够在不间断服务的情况下进行软件版本的升级。
到这里，我们对nginx有了一个基本的认识，后面将分别进行nginx的WEB服务和代理服务相关的应用配置……
【参考资料】
1、nginx官网文档：http://nginx.org/en/docs/
2、nginx源码
3、Web服务器之Nginx详解：http://freeloda.blog.51cto.com/2033581/1285332
4、Nginx 多进程连接请求/事件分发流程分析：http://www.cnblogs.com/NerdWill/p/4992345.html
5、Nginx配置详解：http://www.cnblogs.com/knowledgesea/p/5175711.html
================
对比
对于数据流量过大的网络中，往往单一设备无法承担，需要多台设备进行数据分流，而负载均衡器就是用来将数据分流到多台设备的一个转发器。
目前有许多不同的负载均衡技术用以满足不同的应用需求，如软/硬件负载均衡、本地/全局负载均衡、更高网络层负载均衡，以及链路聚合技术。
我们使用的是软负载均衡器Nginx,而农行用的是F5硬负载均衡器，这里就简单介绍下这两种技术：
a.软件负载均衡解决方案
在一台服务器的操作系统上，安装一个附加软件来实现负载均衡，如Nginx负载均衡（我们管理系统平台使用的也是这款均衡器）。它的优点是基于特定环境、配置简单、使用灵活、成本低廉，可以满足大部分的负载均衡需求。
一、什么是Nginx
Nginx ("engine x") 是一个高性能的 HTTP 和 反向代理 服务器，也是一个 IMAP/POP3/SMTP 代理服务器。 可以说Nginx 是目前使用最为广泛的HTTP软负载均衡器，其将源代码以类BSD许可证的形式发布（商业友好），同时因高效的性能、稳定性、丰富的功能集、示例配置文件和低系统资源的消耗而闻名于业界。像腾讯、淘宝、新浪等大型门户及商业网站都采用Nginx进行HTTP网站的数据分流。
二、Nginx的功能特点
1、工作在网络的7层之上，可以针对http应用做一些分流的策略，比如针对域名、目录结构；
2、Nginx对网络的依赖比较小；
3、Nginx安装和配置比较简单，测试起来比较方便；
4、也可以承担高的负载压力且稳定，一般能支撑超过1万次的并发；
5、Nginx可以通过端口检测到服务器内部的故障，比如根据服务器处理网页返回的状态码、超时等等，www.linuxidc.com 并且会把返回错误的请求重新提交到另一个节点，不过其中缺点就是不支持url来检测；
6、Nginx对请求的异步处理可以帮助节点服务器减轻负载；
7、Nginx能支持http和Email，这样就在适用范围上面小很多；
8、不支持Session的保持、对Big request header的支持不是很好，另外默认的只有Round-robin和IP-hash两种负载均衡算法。
三、Nginx的原理
Nginx采用的是反向代理技术，代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个服务器。反向代理负载均衡技术是把将来自internet上的连接请求以反向代理的方式动态地转发给内部网络上的多台服务器进行处理，从而达到负载均衡的目的。
b.硬件负载均衡解决方案
直接在服务器和外部网络间安装负载均衡设备，这种设备我们通常称之为负载均衡器。由于专门的设备完成专门的任务，独立于操作系统，整体性能得到大量提高，加上多样化的负载均衡策略，智能化的流量管理，可达到最佳的负载均衡需求。 一般而言，硬件负载均衡在功能、性能上优于软件方式，不过成本昂贵，比如最常见的就是F5负载均衡器。
什么是F5 BIG-IP
F5负载均衡器是应用交付网络的全球领导者F5 Networks公司提供的一个负载均衡器专用设备，F5 BIG-IP LTM 的官方名称叫做本地流量管理器，可以做4-7层负载均衡，具有负载均衡、应用交换、会话交换、状态监控、智能网络地址转换、通用持续性、响应错误处理、IPv6网关、高级路由、智能端口镜像、SSL加速、智能HTTP压缩、TCP优化、第7层速率整形、内容缓冲、内容转换、连接加速、高速缓存、Cookie加密、选择性内容加密、应用攻击过滤、拒绝服务(DoS)攻击和SYN Flood保护、防火墙—包过滤、包消毒等功能。
以下是F5 BIG-IP用作HTTP负载均衡器的主要功能：
①、F5 BIG-IP提供12种灵活的算法将所有流量均衡的分配到各个服务器，而面对用户，只是一台虚拟服务器。
②、F5 BIG-IP可以确认应用程序能否对请求返回对应的数据。假如F5 BIG-IP后面的某一台服务器发生服务停止、死机等故障，F5会检查出来并将该服务器标识为宕机，从而不将用户的访问请求传送到该台发生故障的服务器上。这样，只要其它的服务器正常，用户的访问就不会受到影响。宕机一旦修复，F5 BIG-IP就会自动查证应用已能对客户请求作出正确响应并恢复向该服务器传送。
③、F5 BIG-IP具有动态Session的会话保持功能。
④、F5 BIG-IP的iRules功能可以做HTTP内容过滤，根据不同的域名、URL，将访问请求传送到不同的服务器。
方案优缺点对比
基于硬件的方式(F5)
优点：能够直接通过智能交换机实现,处理能力更强，而且与系统无关，负载性能强更适用于一大堆设备、大访问量、简单应用
缺点：成本高，除设备价格高昂，而且配置冗余．很难想象后面服务器做一个集群，但最关键的负载均衡设备却是单点配置；无法有效掌握服务器及应用状态.
硬件负载均衡，一般都不管实际系统与应用的状态，而只是从网络层来判断，所以有时候系统处理能力已经不行了，但网络可能还来 得及反应（这种情况非常典型，比如应用服务器后面内存已经占用很多，但还没有彻底不行，如果网络传输量不大就未必在网络层能反映出来）
基于软件的方式(Nginx)
优点：基于系统与应用的负载均衡，能够更好地根据系统与应用的状况来分配负载。这对于复杂应用是很重要的，性价比高，实际上如果几台服务器，用F5之类的硬件产品显得有些浪费，而用软件就要合算得多，因为服务器同时还可以跑应用做集群等。
缺点：负载能力受服务器本身性能的影响，性能越好，负载能力越大。
综述：对我们管理系统应用环境来说，由于负载均衡器本身不需要对数据进行处理，性能瓶颈更多的是在于后台服务器，通常采用软负载均衡器已非常够用且其商业友好的软件源码授权使得我们可以非常灵活的设计，无逢的和我们管理系统平台相结合。
扫一扫
1155
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
