Nginx是什么？
由俄罗斯开发的反向代理服务器。Nginx 是Web服务器或反向代理服务器。
优点：
- 跨平台：Nginx 可以在大多数 Unix like OS编译运行，而且也有Windows的移植版本。
- 配置异常简单：非常容易上手。配置风格跟程序开发一样，神一般的配置
- 非阻塞、高并发连接：数据复制时，磁盘I/O的第一阶段是非阻塞的。官方测试能够支撑5万并发连接，在实际生产环境中跑到2～3万并发连接数.(这得益于Nginx使用了最新的epoll模型)
- 事件驱动：通信机制采用epoll模型，支持更大的并发连接。
特点：
- nginx代理和后端web服务器间无需长连接；
- 接收用户请求是异步的，即先将用户请求全部接收下来，再一次性发送后后端web服务器，极大的减轻后端web服务器的压力
- 发送响应报文时，是边接收来自后端web服务器的数据，边发送给客户端的
- 网络依赖型低。NGINX对网络的依赖程度非常低，理论上讲，只要能够ping通就可以实施负载均衡，而且可以有效区分内网和外网流量
5、支持服务器检测。NGINX能够根据应用服务器处理页面返回的状态码、超时信息等检测服务器是否出现故障，并及时返回错误的请求重新提交到其它节点上
通过一个实例了解nginx
假设有三台服务器，一台是nginx服务器，两台是tomcat服务器（至少两台）
| 服务器 | 地址 | 用途 |
| Nginx | 192.168.129.10 | 反向代理 |
| Tomcat1 | 192.168.129.11 | 运行tomcat |
| Tomcat1 | 192.168.129.12 | 运行tomcat |
当浏览器发送请求时，是通过nginx来访问tomcat，获得数据后再由nginx传给浏览器显示。浏览器只能获得数据，不能知道是哪一个tomcat把数据传给他的，当然浏览器更是不想知道这些数据的，这样保护了tomcat服务器上的资源安全，这就是反向代理
下图是实际用户通过nginx访问数据，原始资源服务器被防火墙和nginx同时保护：
用户A始终认为它访问的是原始服务器B而不是代理服务器Z，但实用际上反向代理服务器接受用户A的应答，从原始资源服务器B中取得用户A的需求资源，然后发送给用户A。由于防火墙的作用，只允许代理服务器Z访问原始资源服务器B。尽管在这个虚拟的环境下，防火墙和反向代理的共同作用保护了原始资源服务器B，但用户A并不知情。
实例步骤：
在linux环境下，在两个tomcat1和tomcat2服务器下，启动tomcat
-1.上传tomcat的压缩包，解压到指定目录
tar zxvf apache-tomcat-7.0.68.tar.gz
-2.到解压目录找到批处理文件，开启tomcat
cd apache-tomcat-7.0.68
./bin/startup.sh
-3.可以查看一下日志文件，看是否成功
tailf ./logs/catalina.out
修改nginx.conf
vi /usr/local/nginx/conf/nginx.conf
在http节点下添加upstream（服务器集群），server设置的是集群服务器的信息，我这里搭建了两个站点，配置了两条信息。
#新加服务器集群名称为Jq_one
upstream localhost_jp{
server 192.168.129.11:8080;
server 192.168.129.12:8080;
}
#在http节点下找到location节点修改
location / {
root /home/ftpuser/www;
index index.html index.htm;
#设置主机头和客户端真实地址，以便服务器获取客户端真实IP
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_connect_timeout 10;
#发送超时时间
proxy_send_timeout 10;
#接收超时时间
proxy_read_timeout 10;
#反向代理配置
proxy_pass http://localhost_jp;
}
保存之后，你就可以试一下访问192.168.129.10，返回的页面有可能是tomcat1，有可能是tomcat2中的数据
关于nginx选哪一个tomcat服务器，是有五种负载均衡策略的，下面介绍一下：
-1.轮循
默认采用此策略，根据访问的先后的时间，循环的访问代理服务。
-2.Ip_hash
同一ip，始终访问同一代理的服务。
upstream localhost_jp{
ip_hash;
server 192.168.129.11:8080;
server 192.168.129.12:8080;
}
-3.权重
根据设置权重的值，自动计算百分比。
upstream localhost_jp{
server 192.168.129.11:8080 weight=800;
server 192.168.129.12:8080 weight=200;
}
-4.Fair
根据每个地址响应的时间，分配资源。时间越短，越优先访问。
-5.Url_hash
更具url地址计算hash值，同一url始终从同一服务器获取内容，常用于cdn。
Nginx的内部(进程)模型
nginx是以多进程的方式来工作的，当然nginx也是支持多线程的方式的,只是我们主流的方式还是多进程的方式，也是nginx的默认方式。nginx采用多进程的方式有诸多好处 .
(1) nginx在启动后，会有一个master进程和多个worker进程。master进程主要用来管理worker进程，包含：接收来自外界的信号，向各worker进程发送信号，监控 worker进程的运行状态,当worker进程退出后(异常情况下)，会自动重新启动新的worker进程。而基本的网络事件，则是放在worker进程中来处理了 。多个worker进程之间是对等的，他们同等竞争来自客户端的请求，各进程互相之间是独立的 。一个请求，只可能在一个worker进程中处理，一个worker进程，不可能处理其它进程的请求。 worker进程的个数是可以设置的，一般我们会设置与机器cpu核数一致，这里面的原因与nginx的进程模型以及事件处理模型是分不开的 。
(2)Master接收到信号以后怎样进行处理（./nginx -s reload ）?首先master进程在接到信号后，会先重新加载配置文件，然后再启动新的进程，并向所有老的进程发送信号，告诉他们可以光荣退休了。新的进程在启动后，就开始接收新的请求，而老的进程在收到来自master的信号后，就不再接收新的请求，并且在当前进程中的所有未处理完的请求处理完成后，再退出 .
(3) worker进程又是如何处理请求的呢？我们前面有提到，worker进程之间是平等的，每个进程，处理请求的机会也是一样的。当我们提供80端口的http服务时，一个连接请求过来，每个进程都有可能处理这个连接，怎么做到的呢？首先，每个worker进程都是从master进程fork过来，在master进程里面，先建立好需要listen的socket之后，然后再fork出多个worker进程，这样每个worker进程都可以去accept这个socket(当然不是同一个socket，只是每个进程的这个socket会监控在同一个ip地址与端口，这个在网络协议里面是允许的)。一般来说，当一个连接进来后，所有在accept在这个socket上面的进程，都会收到通知，而只有一个进程可以accept这个连接，其它的则accept失败，这是所谓的惊群现象。当然，nginx也不会视而不见，所以nginx提供了一个accept_mutex这个东西，从名字上，我们可以看这是一个加在accept上的一把共享锁。有了这把锁之后，同一时刻，就只会有一个进程在accpet连接，这样就不会有惊群问题了。accept_mutex是一个可控选项，我们可以显示地关掉，默认是打开的。当一个worker进程在accept这个连接之后，就开始读取请求，解析请求，处理请求，产生数据后，再返回给客户端，最后才断开连接，这样一个完整的请求就是这样的了。我们可以看到，一个请求，完全由worker进程来处理，而且只在一个worker进程中处理。
(4):，nginx采用这种进程模型有什么好处呢？采用独立的进程，可以让互相之间不会影响，一个进程退出后，其它进程还在工作，服务不会中断，master进程则很快重新启动新的worker进程。当然，worker进程的异常退出，肯定是程序有bug了，异常退出，会导致当前worker上的所有请求失败，不过不会影响到所有请求，所以降低了风险。当然，好处还有很多，大家可以慢慢体会。
(5).有人可能要问了，nginx采用多worker的方式来处理请求，每个worker里面只有一个主线程，那能够处理的并发数很有限啊，多少个worker就能处理多少个并发，何来高并发呢？非也，这就是nginx的高明之处，nginx采用了异步非阻塞的方式来处理请求，也就是说，nginx是可以同时处理成千上万个请求的 .对于IIS服务器每个请求会独占一个工作线程，当并发数上到几千时，就同时有几千的线程在处理请求了。这对操作系统来说，是个不小的挑战，线程带来的内存占用非常大，线程的上下文切换带来的cpu开销很大，自然性能就上不去了，而这些开销完全是没有意义的。我们之前说过，推荐设置worker的个数为cpu的核数，在这里就很容易理解了，更多的worker数，只会导致进程来竞争cpu资源了，从而带来不必要的上下文切换。而且，nginx为了更好的利用多核特性，提供了cpu亲缘性的绑定选项，我们可以将某一个进程绑定在某一个核上，这样就不会因为进程的切换带来cache的失效
Nginx常见配置说明
worker_processes 8;
#nginx进程数，建议设置为等于CPU总核心数
worker_connections 65535;
#单个进程最大连接数（最大连接数=连接数*进程数）
client_header_buffer_size 32k; #上传文件大小限制
large_client_header_buffers 4 64k; #设定请求缓
client_max_body_size 8m; #设定请求缓
autoindex on; #开启目录列表访问，合适下载服务器，默认关闭。
tcp_nopush on; #防止网络阻塞
tcp_nodelay on; #防止网络阻塞
keepalive_timeout 120; #长连接超时时间，单位是秒
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; #压缩等级
upstream blog.ha97.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;
}
#虚拟主机的配置
server
{
#监听端口
listen 80;
#域名可以有多个，用空格隔开
server_name www.ha97.com ha97.com;
index index.html index.htm index.php;
root /data/www/ha97;
location ~ .*.(php|php5)?$
{
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
include fastcgi.conf;
}