① Nginx相关知识点
Nginx是lgor Sysoev为俄罗斯访问量第二的rambler.ru站点设计开发的。从2004年发布至今，凭借开源的力量，已经接近成熟与完善。
Nginx功能丰富，可作为HTTP服务器，也可作为反向代理服务器，邮件服务器。支持FastCGI、SSL、Virtual Host、URL Rewrite、Gzip等功能。并且支持很多第三方的模块扩展。
Nginx的稳定性、功能集、示例配置文件和低系统资源的消耗让他后来居上，在全球活跃的网站中有12.18%的使用比率，大约为2220万个网站。
自行安装
正向代理: 代理服务器站在客户端那边就是正向代理;
反向代理: 代理服务器站在原始服务器那边就是反向代理;
详解参考点击 Nginx正向代理与反向代理
Nginx在做反向代理时，提供性能稳定，并且能够提供配置灵活的转发功能。
Nginx可以根据不同的正则匹配，采取不同的转发策略，比如图片文件结尾的走文件服务器，动态页面走web服务器，只要你正则写的没问题，又有相对应的服务器解决方案，你就可以随心所欲的玩。
并且Nginx对返回结果进行错误页跳转，异常判断等。如果被分发的服务器存在异常，他可以将请求重新转发给另外一台服务器，然后自动去除异常服务器。
如果你的nginx服务器给2台web服务器做代理，负载均衡算法采用轮询，那么当你的一台机器web程序iis关闭，也就是说web不能访问，那么nginx服务器分发请求还是会给这台不能访问的web服务器，如果这里的响应连接时间过长，就会导致客户端的页面一直在等待响应，对用户来说体验就打打折扣，这里我们怎么避免这样的情况发生呢。这里我配张图来说明下问题。
如果负载均衡中其中web2发生这样的情况，nginx首先会去web1请求，但是nginx在配置不当的情况下会继续分发请求道web2，然后等待web2响应，直到我们的响应时间超时，才会把请求重新分发给web1，这里的响应时间如果过长，用户等待的时间就会越长。
下面的配置是解决方案之一:
如果使用upstream指令配置了一组服务器作为被代理服务器，服务器中的访问算法遵循配置的负载均衡规则，同时可以使用该指令配置在发生哪些异常情况时，将请求顺次交由下一组服务器处理。
状态值可以是：error|timeout|invalid_header|http_500|http_502|http_503|http_504|http_404|off
Nginx提供的负载均衡策略有2种：内置策略和扩展策略。
内置策略: 1.轮询;2.加权轮询;3.Ip hash;
扩展策略: 就天马行空，只有你想不到的没有他做不到的啦，你可以参照所有的负载均衡算法，给他一一找出来做下实现。
Ip hash算法，对客户端请求的ip进行hash操作，然后根据hash结果将同一个客户端ip的请求分发给同一台服务器进行处理，可以解决session不共享的问题。
eg:
开启简单的缓存配置，只需要两个指令：proxy_cache_path和proxy_cache。
proxy_cache_path: 配置缓存的存放地址和其他的一些常用配置;
proxy_cache:指令是为了启动缓存;
相关配置说明:
该指令用于定义满足条件的响应不会被保存到缓存中。在条件字符串中至少有一个条件不为空或者0，符合这样条件的响应才不会被缓存。
举例如下
其中，cookie_nocache、arg_nocache...皆为变量，可以根据你访问的匹配策略来设置，其值只有2类，0和非0;
访问匹配策略例如：
如果在此链式配置中，只要有一个值不为0，则不会cache；例如：
则不会被cache.
注：一般会配合proxy_cache_bypass共同使用；
该指令用于定义哪些情况不从cache读取，直接从backend获取资源；配置方式同proxy_no_cache。
给缓存数据定义一个键，例如
该指令用于设置缓存哪些HTTP方法,默认缓存HTTP GET/HEAD方法,不缓存HTTP POST 方法.。
设置不同响应码的缓存时间，当不指定响应码的时候，例如
只对响应码为200，301，302的访问请求资源设置缓存时间，此外可以个性化定制，例如：
此外，还可以在相应header里设置优先级更高的缓存有效时间：
不缓存包含在field的响应header，可以设置的值有：“X-Accel-Redirect”, “X-Accel-Expires”, “X-Accel-Limit-Rate”，“X-Accel-Buffering”, “X-Accel-Charset”, “Expires”, “Cache-Control”, “Set-Cookie” (0.8.44), and “Vary”。
如果上述的header field没有设置为忽略，则header filed中有“X-Accel-Expires”, “Expires”, “Cache-Control”, “Set-Cookie”, and “Vary”的话，响应会被缓存。
该指令用于设置缓存的最小使用次数,默认值为1
源站有问题时，nginx可以通过proxy_cache_use_stale指令开启容错能力，即使用缓存内容来响应客户端的请求。举例如下：
如上配置表示，当作为cache的NGINX收到源站返回error、timeout或者其他指定的5XX错误，并且在其缓存中有请求文件的陈旧版本，则会将这些陈旧版本的文件而不是错误信息发送给客户端。
使用NGINX，不需要建立一个RAID（磁盘阵列）。如果有多个硬盘，NGINX可以用来在多个硬盘之间分割缓存。举例如下：
在这份配置中，使用了3个独立的缓存，每个缓存专用一块硬盘，另外，3个独立的线程池也各自专用一块硬盘。
缓存之间（其结果就是磁盘之间）的负载均衡使用split_clients模块，split_clients非常适用于这个任务。
在 proxy_cache_path指令中设置 use_temp_path=off ，表示NGINX会将临时文件保存在缓存数据的同一目录中。这是为了避免在更新缓存时，磁盘之间互相复制响应数据。
通过访问日志，你可以得到用户地域来源、跳转来源、使用终端、某个URL访问量等相关信息；
通过错误日志，你可以得到系统某个服务或server的性能瓶颈等。
因此，将日志好好利用，你可以得到很多有价值的信息。
打开nginx.conf配置文件：vim /usr/local/nginx/conf/nginx.conf
日志部分内容：
#access_log logs/access.log main;
日志生成的到Nginx根目录logs/access.log文件，默认使用“main”日志格式，也可以自定义格式。
默认“main”日志格式：
参数明细表：
查看日志命令tail -f /usr/local/nginx/logs/access.log
打开nginx.conf配置文件去掉#注释见下图：
自定义某一个server配置的日志，使用“main”日志格式。
日志生成的到Nginx根目录logs/access.log文件，默认使用“main”日志格式，也可以自定义格式。
重新读取加载Nginx配置文件：
执行命令：nginx-s reload
网上一位老师写的log文件分解的脚本
此脚本执行时间根据自己公司情况来定,可以设置默认一天执行一次;
创建crontab设置作业
设置日志文件存放目录crontab -e
*/1 * * * * sh /usr/local/software/nginx/nginx_log.sh
此设置的为一分钟,如果设置一天自行修改;
默认的 nginx 配置文件 nginx.conf 内容如下
示例
几个常见配置项：
注意:
惊群现象：一个网路连接到来，多个睡眠的进程被同事叫醒，但只有一个进程能获得链接，这样会影响系统性能
每个指令必须有分号结束。
进入安装目录下的sbin
② 多个nginx如何分发，达到负载均衡。国内大型网站一般如何实现的
这方面的资料，基本都是一块一块不完整的。我大概跟你说一个基本架构：
1、DNS服务器，如果资金充足的话，建议使用BGP机房，2-3台DNS服务器均衡，通常使用bind软件。如果资金紧的话，可以购买专业的dns服务，比如国内的dnspod。
2、CDN服务器，一开始如果想省事，可以买专业公司的服务，如chinacache，但随着发展成本会越来越高。自建的话，可能分别搭建，放电信、联通、移动等不同机房的服务器，通过dns做动态解析。超大网站的话，可以用Squid，普通中至大型用nginx，内部玩玩用varnish。
3、前端均衡，资金充足的话，可以使用硬件设备，几十万一台。自已有技术队伍的话，就用nginx/haproxy+keepalived等自已组建前端。均衡的方式都比较灵活，随机、权重、ip、url都有。
4、同步的问题要看同步什么东西，普通的可以实时文件同步。但数据库的话，要看具体类型选择同步方式了。
5、后端的应用服务器和数据库集群，要看流量规划了。
③ 负载均衡——LVS，HAProxy和Nginx对比分析
负载均衡（Load Balance）是应用于互联网后台系统架构颤孝设计中的各层，它将请求均匀分摊到多个操作单元上执行。
目前，在线上环境中应用较多的负载均衡器硬件有F5 BIG-IP，但是硬件设备昂贵，不如软件适应互联网公司的快速发展。最常用的负载均衡软件有LVS、HAProxy和Nginx，结合高可用软件有Heartbeat、Keepalived，可以搭建出承载海量请求的成熟架构如LVS+Keepalived、HAProxy+keepalived等.
三种负载均衡软件LVS、HAProxy和Nginx的优缺点说明如下：
LVS的优点：
LVS的缺点：
HAProxy的优点：
Nginx的优点轮宴：
Nginx的缺点：
简单地不负责任地说，性能上LVS>HA>Nginx，功能性和便利性上Nginx>HA>LVS。
对于一个大型后台系统来说，LVS、HAProxy和Nginx常常可以配合使用在不同的层级，LVS用在接入层的最前端，承担最大规模的流量分发；HAProxy负责按域名分流；而Nginx只需要作为Web服务器负责单机内多实例的负载均衡，或负责目录结构分流和静态资源缓存等需求。
所谓的四层与七层负载均衡，就是在对后台服务器进行负载均衡时，依茄桐稿据OSI四层的信息或七层的信息来决定怎么样转发流量。比如四层负载均衡通过报文中的目标IP地址和端口，七层负载均衡通过报文中的应用层信息(URL、HTTP头部等信息)，选择到达目的的内部服务器。四层负载均衡在解包上的消耗更少，可以达到更高的性能。而七层负载算法可以通过更多的应用层信息分发请求，功能性上更强大。
七层负载均衡软件可以通过URL、Cookie和HTTP head等信息，而不仅仅是IP端口分发流量，还可以修改客户端的请求和服务器的响应（例如HTTP请求中的Header的重写），极大提升了应用系统在网络层的灵活性。
在网络中常见的SYN Flood攻击中，黑客会对同一目标大量发送SYN报文，耗尽服务器上的相关资源，以达到Denial of Service(DoS)的目的。四层模式下这些SYN攻击都会被转发到后端的服务器上；而在七层模式下这些SYN攻击在负载均衡设备上就截止，不会影响后台服务器的正常运营。另外负载均衡设备可以在七层层面设定多种策略，过滤sql Injection等应用层面的特定攻击手段，进一步提高系统整体安全。
④ Nginx多台服务器实现负载均衡
Nginx负载均衡服务器： IP：192.168.0.4（Nginx-Server）
Web服务器列表：
Web1: 192.168.0.5（Nginx-Node1/Nginx-Web1）
Web2:192.168.0.7（Nginx-Node2/Nginx-Web2）
实简困让现目的：用户访问Nginx-Server时，通过Nginx负载均衡到Web1和Web2服务器。
配置注释如下：尺槐
创建文件夹准备存放配置文件
启动负载均衡服务器192.168.0.4（Nginx-Server）
创建文件夹用于存放web页面
编辑内容如下：
启动192.168.0.5（Nginx-Node1/Nginx-Web1）
创建文件夹用于存放web页面
编辑拦局内容如下：
启动192.168.0.7（Nginx-Node2/Nginx-Web2）
⑤ 负载均衡：F5，Haproxy，lvs, nginx
阅读本文前，需熟悉OSI七层参考模型。
常见的负载均衡设备，有F5，Haproxy，lvs, nginx等。
F5是商用硬件负载均衡，性能很好，但是价格昂贵，除了负载均衡，还有应用交换、会话交换、状态监控等众多功能。
F5一般做四层负载均衡，但也支持七层负载均衡。
Haproxy(以下简称ha)是软哗唯岁件负载均衡，开源，一般做七层负载均衡，但也支持四层负载均衡。
Linux Virtual Server(以下简称lvs)是软件负载均衡，开源，二层或四层负载均衡，已集成到linux内核，自身有完备的热备方案（keepalived+lvs），稳定性极强。
nginx也是软件负载均衡，开源，通过反向代理实现负载均衡，是七层负载均衡，性能不如上面的几个。
tips1
有些公司，测试环境用ha/lvs/nginx，生产环境用F5。
tips2
nginx做web服务器时，一般做静态资源服务器和php的web服务器，所以很多公司，会采用F5+nginx或者ha+nginx的架构
tips3
微服务中的ribbon属于客户端负载均衡，上面的几种都是服务端负载均衡
二层负载均衡
在数据链路层通过修改mac地址实现，如lvs的DR模式（直接路由模式）
三层负载均衡
在网络层通过DNAT协议修改目标地址实现
四层负载均衡
用ip+端口实现请求转发
备注：tcp报文里并没有ip，但是四层负载均衡可以用ip+端口，是因为server可以拿到ip
七层负载均衡
通过重新发起http请求实现，即client把请求发给lb，lb把请求代发给server，再把server的响应返回给client，因此七层负载均衡也经常被称为代理，七层负载均衡设备也被称为代理设备。
七层负载均衡常用于内网与外网的通信，比如内网无法直接访问外网，需要通过代理设备代发http请求，这种情况下，代理设备需要配置双网卡，以同时与内外网络通信。
由于山宽需要重发http请求，七层负载均衡性能较差，但是更智能和安全，因为应用层可以获取甚至修改请求的真实内容（即应用数据），比如cookie、url等，可以做一些智能的操作，比如根据cookie/url转发请求，也可以做一些安全操作，比如过滤特定报文、防止SYN Flood攻击等。
使用七层负载均衡时，服务的性能受限于代理设备的网卡带宽。
常见的负载均衡策略，有轮询、加权轮询、ip_hash、cookie、url_hash，根据服务器响应时间转发、根据最少连接转发等等。
备注：nginx可以安装第三方插件，使用第三方实现的策略
轮询：按服务器列表顺序转发请求，轮询是nginx默认的策略，本策略适合服务器配置相当、请求无状态（即不依赖session）的场景
加权轮询：如果不同服务器配置不同，可以为配乱睁置高的服务器增加权重
ip_hash：根据ip哈希结果转发，可以实现同一用户持续请求同一服务器（即会话保持），适合有状态（即依赖session）的场景，对png、jpg、js、css等静态资源的请求，不适合使用本策略
cookie：根据特定cookie转发请求，一般也是用于实现会话保持，比如为服务器A、B分别增加service-flag=a、service-flag=b的cookie，后续请求根据cookie转发
可以参考 haproxy实现会话保持
url_hash：根据url哈希结果转发，同一个接口始终请求同一台服务器，一般配合缓存使用，缓存接口返回结果
根据服务器响应时间转发：优先转发到响应时间较快的服务器
根据最少连接转发：优先转发到连接数较少的服务器
F5有一些特有的负载均衡策略：利用从应用程序和服务器收集到的各项性能指标，分析并转发
负载均衡有两个步骤：
1.根据什么算法选择真实服务端，即负载均衡策略，如轮询、加权轮询、ip_hash、cookie、url_hash等；
2.把请求转发到真实服务器，转发方式有二层到七层负载均衡
keepalived软件一开始是专为lvs设计的，后来加入了可以实现高可用的VRRP (Virtual Router Rendancy Protocol ,虚拟路由器冗余协议）功能，因此，keepalived还可以作为nginx、haproxy、mysql等服务的高可用解决方案。
以nginx为例，为了防止nginx本身由于宕机等原因导致网站不可用，一般会搭两套nginx反向代理，用keepalived提供一个VIP。
一般情况下，VIP只在nginx主节点上工作，如果nginx主节点不可用了，VIP会自动漂移到从节点，自动漂移的原理即VRRP协议。
VIP漂移到从节点后，如果主节点恢复正常了，VIP是否漂移回主节点，取决于当前模式是抢占模式还是非抢占模式。
下图是一张简单的架构图，解释如下：
以上观点纯属个人意见，如果错误，欢迎指出，有些地方写的很简单，是因为我也不懂~
⑥ nginx在做负载均衡时如何配置
1、下面的架构就是我们今天的演示结构，后端有两台服务器，分别是node1和node2，前端是一台web服务器，然后在web服务器上做负载均衡，将前端的访问流量导到后端的两个节点服务器上。三个服务器的IP地址分别是：web：192.168.1.210node1：192.168.1.211node2：192.168.1.212
2、按照这样的架构，在后端的node1和node2节点上分配配置好需要访问的网站，然后为了方便测试，我们将两个网站的主页分别改成下面的内容。便于区分访问的节点。
3、后端两个节点配置好以后，我们再来配置web服务器里的负载均衡配置，首先使用默认配置，先打开/etc/nginx/nginx.conf配置文件，在http区块里添加upstream块内容，及配置了两个后端服务器，后端负载均衡集群的名称是backend，记下这个名称。
4、然后再打开/etc/nginx/conf.d/default.conf这个配置文件，在server区块里，把location里面的内容改成图中所示内容。即将所有访问192.168.1.210的流量代理到后端的backend集群里。
5、配置文件配置好以后，使用nginx-t命令测试一下配置文件，保证配置文件是ok状态，然后执行nginx命令启动nginx服务器。
6、启动后在浏览器上输入前端web服务器的ip地址192.168.1.210，然后可以看到第一次是node1响应的，然后刷新一下以后，又变成了node2响应的。就这样实现了负载均衡的效果。由两个服务器分别响应，是因为默认的负载均衡算法是轮询算法，即两个节点轮流来。
7、然后我们还可以尝试一下加权轮询算法，即给不同的节点配置不同的权重，权重高一点的服务器，响应的多一些，权重第一点的响应少一些。加权轮询算法配置，在后端服务器后面加上权重值weight即可。配置好以后，执行nginx-t命令检测配置文件，确认无误后，执行nginx-sreload命令重新加载配置文件。
8、通过加权轮询的方式，我们无法通过手动一次次点击，最后来统计次数。但是我们可以使用自动化工具来统计。使用的工具是一款叫做httpd-tools的软件，安装好以后，提供了一个ab命令
9、然后我们来执行ab命令进行测试，常用的格式是：ab-n1000-c50http://localhost这个命令是在210服务器上执行的。表示一共执行1000次访问，每次发送50个请求。
10、然后我们登录到后端的node1服务器上，打开nginx的访问日志，从中可以看到ab命令测试的访问信息里，访问来源都是ApacheBench，因此可以通过可以来源来统计nginx响应的次数。命令是：grepApacheBenchaccess.log|wcnode1和node2节点上的统计结果分别是714和286，如下面图中所示，虽然没有达到5:2的权重比例，但是也非常接近了。说明这个配置生效了。
⑦ 如何在一台pc上做nginx负载均衡
一、实验环境
阅读本文前，假定读者对nginx安装、虚拟机的安装有了解，并未对这些内容作详细介绍。
一台pc
pc安装的操作系统为win7，使用vmware虚拟两台linux，pc 连接到了一台交换机，IP为： 192.168.1.100
nginx版本为1.05，其中win7为负载均衡代理机器，虚拟的linux为web服务器
vmware配置时，在网络连接一项选： bridged，两台虚拟机的ip分别为： 192.168.1.102,192.168.1.103
二、配置文件
1 win7用于负载均衡的nginx的配置文件如下(nginx.conf)，修改完后可再控制台输入： nginx -t，来测试修改的配置文件是否正确。
upstream test {
server 192.168.1.102;
server 192.168.1.103;
}
server {
listen 80;
server_name localhost;
charset gbk;
#access_log logs/host.access.log main;
location / {
proxy_next_upstream error timeout invalid_header http_500
http_502 http_503 http_504 http_404;
proxy_connect_timeout 10s;
proxy_read_timeout 2s;
#proxy_send_timeout 10s;
proxy_pass http://test;
}
2 linux上作为web服务器的nginx的配置文件可为默认，没有变化
3 修改作为web服务器的nginx，html目录下的index.html，在Welcome to nginx!后面加上描述： i am server x!,这一步是为了区分服务是否生效。
三、运行服务
1.win7:直接在控制台输入：nginx即可
2.linux:nginx -c ./conf/nginx.conf
如果运行成功，这时在你win7的浏览器中输入http://192.168.1.100 ，这时会有i am server 2显示，按f5刷新，server名字每次都会变化！
四、结论
本文只是在一台机器上简单对轮询试负载均衡做了简单的测试。
后续的实验，将全部在此机器上做测试了
⑧ 我用nginx配置webservice负载均衡，怎么弄
简单的宏戚负载均衡配衡绝判置 upstream backend { server backend1.example.com weight=5;#weight权重，权重越高发送咐改到此台服务器的请求概率越大 server backend2.example.com:8080; server backup1.example.com:8080 backup;#backup备份服务器，只有在非backup服务器都不能访问时才会向此服务器分流
⑨ Nginx，一看就会
Nginx("engine x") 是一个高性能的 HTTP 和反向代理服务器,特点是占有内存少，并发能力强，事实上 nginx 的并发能力确实在同类型的网页服务器中表现较好，中国大陆使用 nginx 网站用户有：雀改网络、京东、新浪、网易、腾讯、 淘宝等。
1.1 WEB 服务器
Nginx 可以作为静态页面的 web 服务器，同时还支持 CGI 协议的动态语言，比如 perl、php
等。但是不支持 java。Java 程序只能通过与 tomcat 配合完成。Nginx 专为性能优化而开发，性能是其最重要的考量,实现上非常注重效率 ，能经受高负载的考验,有报告表明能支持高达 50000个并发连接数。
1.2 反向代理
1.正向代理，代理客户端，客户端需要配置代理
2.反向代理，代理服务端，客户端无感知
1.3 负载均衡
Nginx 的异步框架可以处理很大的并发请求，把这些并发请求 hold 住之后就可以分发给后台服务端(backend servers，也叫做服务池， 后面简称 backend)来做复杂的计算、处理和响应，这种模式的好处是相当多的：隐藏业务主机更安全，节约了公网 IP 地址，并且在业务量增加的时候可以方顷碧判便地扩容后台服务器。
这时候集群的概念产生了，我们增加服务器的数量，然后将请求分发到各个服务器上，将原先请求集中到单个服务器上的情况改为将请求分发到多个服务器上，将负载分发到不同的服器，也就是我们所说的负载均衡。
1.4 动静分离
为了加快网站的解析速度，可以把动态页面和静态页面由不同的服务器来解析，加快解析速度。降低原来单个服务器的压力。
Nginx官网
2.1 相关安装包
pcre-8.37.tar.gz openssl-1.0.1t.tar.gz zlib-1.2.8.tar.gz nginx-1.11.1.tar.gz
2.2 安装流程
2.1.1.安装 pcre 解压缩 pcre-xx.tar.gz 包
进入解压缩目录，执行./configure
如果提示，需要提前安装 gcc++，进入安装光盘目录的软件包(/media/CentOSXX/Package)执行
rpm -ivh libstdc+ devel-4.4.7-17.el6.x86_64.rpm
rpm -ivh gcc-c+ 4.4.7-17.el6.x86_64.rpm
./configure 完成后，回到 pcre 目录下执行 make，再执行 make install
2.2.2.安装 openssl
解压缩 openssl-xx.tar.gz 包。
进入解压缩目录，执行./config
make && make install
2.2.3.安装 zlib 解压缩 zlib-xx.tar.gz 包。
进入解压缩目录，执行./configure。
make && make install
2.2.4.安装 nginx
解压缩 nginx-xx.tar.gz 包。
进入解压缩目录，执行./configure。
make && make install
查看开放的端口号
firewall-cmd --list-all
设置开放的端口号
firewall-cmd --add-service=http –permanent
sudo firewall-cmd --add-port=80/tcp --permanent
重启防火墙
firewall-cmd –reload
2.3 Nginx 启动
命令
启动命令：在/usr/local/nginx/sbin 目录下执行 ./nginx
关闭命令: 在/usr/local/nginx/sbin 目录下执行 ./nginx -s stop
重新加载命令: 在/usr/local/nginx/sbin 目录下执行 ./nginx -s reload·
设置 nginx 为自启动服务
修改慧差 linux 启动脚本/etc/rc.d/rc
加入 :/usr/local/nginx/sbin/nginx
nginx 安装目录下，其默认的配置文件都放在conf 目录下，而主配置文件nginx.conf 也在其中，后续对 nginx 的使用基本上都是对此配置文件进行相应的修改。
根据上述文件，我们可以很明显的将 nginx.conf 配置文件分为三部分
第一部分：全局块
从配置文件开始到 events 块之间的内容，主要会设置一些影响 nginx 服务器整体运行的配置指令，主要包括配置运行 Nginx 服务器的用户（组）、允许生成的 worker process 数，进程 PID 存放路径、日志存放路径和类型以及配置文件的引入等。
比如上面第一行配置的：worker_processes 1;
这是 Nginx 服务器并发处理服务的关键配置，worker_processes 值越大，可以支持的并发处理量也越多，但是会受到硬件、软件等设备的制约。
第二部分：events 块
events 块涉及的指令主要影响 Nginx 服务器与用户的网络连接，常用的设置包括是否开启对多 work process 下的网络连接进行序列化，是否允许同时接收多个网络连接，选取哪种事件驱动模型来处理连接请求，每个 word process 可以同时支持的最大连接数等。
上述例子就表示每个 work process 支持的最大连接数为 1024.
这部分的配置对 Nginx 的性能影响较大，在实际中应该灵活配置。
第三部分：http 块
这算是 Nginx 服务器配置中最频繁的部分，代理、缓存和日志定义等绝大多数功能和第三方模块的配置都在这里。
需要注意的是：http 块也可以包括 http 全局块、server 块。
http 全局块
http 全局块配置的指令包括文件引入、MIME-TYPE 定义、日志自定义、连接超时时间、单链接请求数上限等。
server 块
这块和虚拟主机有密切关系，虚拟主机从用户角度看，和一台独立的硬件主机是完全一样的，该技术的产生是为了节省互联网服务器硬件成本。
每个 http 块可以包括多个 server 块，而每个 server 块就相当于一个虚拟主机。
而每个 server 块也分为全局 server 块，以及可以同时包含多个 locaton 块。
全局 server 块
最常见的配置是本虚拟机主机的监听配置和本虚拟主机的名称或 IP 配置。
location 块
一个 server 块可以配置多个 location 块。
这块的主要作用是基于 Nginx 服务器接收到的请求字符串（例如 server_name/uri-string），对虚拟主机名称（也可以是 IP 别名）之外的字符串（例如 前面的 /uri-string）进行匹配，对特定的请求进行处理。地址定向、数据缓存和应答控制等功能，还有许多第三方模块的配置也在这里进行。
案例配置如下：
location 指令说明
该指令用于匹配 URL，语法如下：
= ：用于不含正则表达式的 uri 前，要求请求字符串与 uri 严格匹配，如果匹配
成功，就停止继续向下搜索并立即处理该请求。
~：用于表示 uri 包含正则表达式，并且区分大小写。
~*：用于表示 uri 包含正则表达式，并且不区分大小写。
^~：用于不含正则表达式的 uri 前，要求 Nginx 服务器找到标识 uri 和请求字
符串匹配度最高的 location 后，立即使用此 location 处理请求，而不再使用 location
块中的正则 uri 和请求字符串做匹配。
注意：如果 uri 包含正则表达式，则必须要有 ~ 或者 ~* 标识。
案例配置如下：
在 linux 下有 Nginx、LVS、Haproxy 等等服务可以提供负载均衡服务，而且 Nginx 提供了几种分配方式(策略)：
轮询（默认）
每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器 down 掉，能自动剔除。
weight
weight 代表权重，默认为 1，权重越高被分配的客户端越多指定轮询几率，weight 和访问比率成正比，用于后端服务器性能不均的情况。
ip_hash
每个请求按访问 ip 的 hash 结果分配，这样每个访客固定访问一个后端服务器，可以解决 session 的问题。
fair（第三方）
按后端服务器的响应时间来分配请求，响应时间短的优先分配。
动静分离从目前实现角度来讲大致分为两种：
1.一种是纯粹把静态文件独立成单独的域名，放在独立的服务器上，也是目前主流推崇的方案；
2.另外一种方法就是动态跟静态文件混合在一起发布，通过 nginx 来分开。
通过 location 指定不同的后缀名实现不同的请求转发。通过 expires 参数设置，可以使浏览器缓存过期时间，减少与服务器之前的请求和流量。具体 Expires 定义：是给一个资源设定一个过期时间，也就是说无需去服务端验证，直接通过浏览器自身确认是否过期即可，所以不会产生额外的流量。此种方法非常适合不经常变动的资源。（如果经常更新的文件，不建议使用 Expires 来缓存），我这里设置 3d，表示在这 3 天之内访问这个 URL，发送一个请求，比对服务器该文件最后更新时间没有变化，则不会从服务器抓取，返回状态码304，如果有修改，则直接从服务器重新下载，返回状态码 200。
master-workers 的机制的好处
首先，对于每个 worker 进程来说，独立的进程，不需要加锁，所以省掉了锁带来的开销，
同时在编程以及问题查找时，也会方便很多。其次，采用独立的进程，可以让互相之间不会
影响，一个进程退出后，其它进程还在工作，服务不会中断，master 进程则很快启动新的
worker 进程。当然，worker 进程的异常退出，肯定是程序有 bug 了，异常退出，会导致当
前 worker 上的所有请求失败，不过不会影响到所有请求，所以降低了风险。
需要设置多少个 worker
Nginx 同 redis 类似都采用了 io 多路复用机制，每个 worker 都是一个独立的进程，但每个进
程里只有一个主线程，通过异步非阻塞的方式来处理请求， 即使是千上万个请求也不在话
下。每个 worker 的线程可以把一个 cpu 的性能发挥到极致。所以 worker 数和服务器的 cpu
数相等是最为适宜的。设少了会浪费 cpu，设多了会造成 cpu 频繁切换上下文带来的损耗。
连接数 worker_connection
这个值是表示每个 worker 进程所能建立连接的最大值，所以，一个 nginx 能建立的最大连接数，应该是 worker_connections * worker_processes。当然，这里说的是最大连接数，对于HTTP 请 求 本 地 资 源 来 说 ， 能 够 支 持 的 最 大 并 发 数 量 是 worker_connections * worker_processes，如果是支持 http1.1 的浏览器每次访问要占两个连接，所以普通的静态访问最大并发数是： worker_connections * worker_processes /2，而如果是 HTTP 作 为反向代理来说，最大并发数量应该是 worker_connections *
worker_processes/4。因为作为反向代理服务器，每个并发会建立与客户端的连接和与后端服务的连接，会占用两个连接。
注意：此部分属于高级技术，近几日会将下面的知识点补充完毕。
8.1 Keepalived+Nginx 高可用集群（主从模式）
8.2 Keepalived+Nginx 高可用集群（双主模式）