前言：最近有打算研读nginx源代码，看到网上介绍nginx可以作为一个反向代理服务器完成负载均衡。所以搜罗了一些关于反向代理服务器的内容，整理综合。
一 、概述
Nginx是一款轻量级的网页服务器、反向代理器以及电子邮件代理服务器。因它的稳定性、丰富的功能集、示例配置文件和低系统资源的消耗而闻名。Nginx（发音同engine x），它是由俄罗斯程序员Igor Sysoev所开发的。起初是供俄国大型的门户网站及搜索引擎Rambler（俄语：Рамблер）使用。此软件BSD-like协议下发行，可以在UNIX、GNU/Linux、BSD、Mac OSX、Solaris，以及Microsoft Windows等操作系统中运行。
反向代理（Reverse Proxy）方式是指以代理服务器来接受Internet上的连接请求，然后将请求转发给内部网络上的服务器；并将从服务器上得到的结果返回给Internet上请求连接的客户端，此时代理服务器对外就表现为一个服务器。
通常的代理服务器，只用于代理内部网络对Internet的连接请求，客户机必须指定代理服务器,并将本来要直接发送到Web服务器上的http请求发送到代理服务器中。当一个代理服务器能够代理外部网络上的主机，访问内部网络时，这种代理服务的方式称为反向代理服务。
Nginx能做什么
- 反向代理
- 负载均衡
- HTTP 服务器（包含动静分离）
- 正向代理
以上就是我了解到的 Nginx 在不依赖第三方模块能处理的事情，下面详细说明每种功能怎么做。
二、nginx主要应用场景
2.1反向代理
反向代理应该是 Nginx 做的最多的一件事了，什么是反向代理呢，以下是百度百科的说法：反向代理（Reverse Proxy）方式是指以代理服务器来接受 internet 上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给 internet 上请求连接的客户端，此时代理服务器对外就表现为一个反向代理服务器。
简单来说就是真实的服务器不能直接被外部网络访问，所以需要一台代理服务器，而代理服务器能被外部网络访问的同时又跟真实服务器在同一个网络环境，当然也可能是同一台服务器，端口不同而已。下面贴上一段简单的实现反向代理的代码：
server { listen 80; server_name localhost; client_max_body_size 1024M; location / { proxy_pass http://localhost:8080; proxy_set_header Host $host:$server_port; } }
保存配置文件后启动 Nginx，这样当我们访问 localhost 的时候，就相当于访问 localhost:8080 了。
2.2负载均衡
负载均衡也是 Nginx 常用的一个功能，负载均衡其意思就是分摊到多个操作单元上进行执行，例如 Web 服务器、FTP 服务器、企业关键应用服务器和其它关键任务服务器等，从而共同完成工作任务。
简单而言就是当有2台或以上服务器时，根据规则随机的将请求分发到指定的服务器上处理，负载均衡配置一般都需要同时配置反向代理，通过反向代理跳转到负载均衡。
Nginx 目前支持自带3种负载均衡策略，还有2种常用的第三方策略。
RR（默认）
每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。
upstream test { server localhost:8080; server localhost:8081; } server { listen 81; server_name localhost; client_max_body_size 1024M; location / { proxy_pass http://test; proxy_set_header Host $host:$server_port; } }
负载均衡的核心代码为：
upstream test { server localhost:8080; server localhost:8081; }
[这里我配置了2台服务器，当然实际上是一台，只是端口不一样而已，而 8081 的服务器是不存在的，也就是说访问不到，但是我们访问 http://localhost 的时候，也不会有问题，会默认跳转到 http://localhost:8080 具体是因为Nginx会自动判断服务器的状态，如果服务器处于不能访问（服务器挂了），就不会跳转到这台服务器，所以也避免了一台服务器挂了影响使用的情况，由于Nginx默认是RR策略，所以我们不需要其他更多的设置。]
2.3权重
指定轮询几率，weight 和访问比率成正比，用于后端服务器性能不均的情况。例如
upstream test { server localhost:8080 weight=9; server localhost:8081 weight=1; }
那么10次一般只会有1次会访问到8081，而有9次会访问到8080。
1）ip_hash
上面的2种方式都有一个问题，那就是下一个请求来的时候请求可能分发到另外一个服务器，当我们的程序不是无状态的时候（采用了 session 保存数据），这时候就有一个很大的很问题了，比如把登录信息保存到了session 中，那么跳转到另外一台服务器的时候就需要重新登录了，所以很多时候我们需要一个客户只访问一个服务器，那么就需要用 iphash 了，iphash 的每个请求按访问 ip 的 hash 结果分配，这样每个访客固定访问一个后端服务器，可以解决 session 的问题。
upstream test { ip_hash; server localhost:8080; server localhost:8081; }
2）fair（第三方）
按后端服务器的响应时间来分配请求，响应时间短的优先分配。
upstream backend { fair; server localhost:8080; server localhost:8081; }
3）url_hash（第三方）
按访问url的hash结果来分配请求，使每个 url 定向到同一个后端服务器，后端服务器为缓存时比较有效。在 upstream 中加入hash语句，server语句中不能写 weight 等其他的参数，hash_method 是使用的hash算法。
upstream backend { hash $request_uri; hash_method crc32; server localhost:8080; server localhost:8081; }
以上5种负载均衡各自适用不同情况下使用，所以可以根据实际情况选择使用哪种策略模式，不过 fair 和 url_hash 需要安装第三方模块才能使用，由于本文主要介绍 Nginx 能做的事情，所以 Nginx 安装第三方模块不会再本文介绍。
2.4HTTP服务器
Nginx 本身也是一个静态资源的服务器，当只有静态资源的时候，就可以使用 Nginx 来做服务器，同时现在也很流行动静分离，就可以通过 Nginx 来实现，首先看看 Nginx 做静态资源服务器。
server { listen 80; server_name localhost; client_max_body_size 1024M; location / { root 地址; index index.html index.htm; } }
这样如果访问http://localhost就会默认访问到 指定目录下面的 index.html，如果一个网站只是静态页面的话，那么就可以通过这种方式来实现部署。
2.5动静分离
动静分离是让动态网站里的动态网页根据一定规则把不变的资源和经常变的资源区分开来，动静资源做好了拆分以后，我们就可以根据静态资源的特点将其做缓存操作，这就是网站静态化处理的核心思路
upstream test{ server localhost:8080; server localhost:8081; } server { listen 80; server_name localhost; location / { root e:\root; index index.html; } # 所有静态请求都由nginx处理，存放目录为html location ~ \.(gif|jpg|jpeg|png|bmp|swf|css|js)$ { root e:\root; } # 所有动态请求都转发给tomcat处理 location ~ \.(jsp|do)$ { proxy_pass http://test; } error_page 500 502 503 504 /50x.html; location = /50x.html { root e:\root; } }
这样我们就可以把 HTML 以及图片和 css 以及 js 放到 root 目录下，而tomcat只负责处理 jsp 和请求，例如当我们后缀为 gif 的时候，Nginx 默认会从 root 获取到当前请求的动态图文件返回，当然这里的静态文件跟 Nginx 是同一台服务器，我们也可以在另外一台服务器，然后通过反向代理和负载均衡配置过去就好了，只要搞清楚了最基本的流程，很多配置就很简单了，另外 localtion 后面其实是一个正则表达式，所以非常灵活。
2.6正向代理
正向代理，意思是一个位于客户端和原始服务器(origin server)之间的服务器，为了从原始服务器取得内容，客户端向代理发送一个请求并指定目标(原始服务器)，然后代理向原始服务器转交请求并将获得的内容返回给客户端，客户端才能使用正向代理。
resolver 114.114.114.114 8.8.8.8; server { resolver_timeout 5s; listen 81; access_log e:\root\proxy.access.log; error_log e:\root\proxy.error.log; location / { proxy_pass http://$host$request_uri; } }
resolver 是配置正向代理的 DNS 服务器，listen 是正向代理的端口，配置好了就可以在 IE 上面或者其他代理插件上面使用服务器 ip+端口号进行代理了。
三、Nginx的特点
（1）跨平台：Nginx 可以在大多数 Unix like OS编译运行，而且也有Windows的移植版本。
（2）配置异常简单，非常容易上手。配置风格跟程序开发一样，神一般的配置
（3）非阻塞、高并发连接：数据复制时，磁盘I/O的第一阶段是非阻塞的。官方测试能够支撑5万并发连接，在实际生产环境中跑到2～3万并发连接数.(这得益于Nginx使用了最新的epoll模型)
（4）事件驱动：通信机制采用epoll模型，支持更大的并发连接。
（5）master/worker结构：一个master进程，生成一个或多个worker进程
（6）内存消耗小：处理大并发的请求内存消耗非常小。在3万并发连接下，开启的10个Nginx 进程才消耗150M内存（15M*10=150M）
（7）成本低廉：Nginx为开源软件，可以免费使用。而购买F5 BIG-IP、NetScaler等硬件负载均衡交换机则需要十多万至几十万人民币
（8）内置的健康检查功能：如果 Nginx Proxy 后端的某台 Web 服务器宕机了，不会影响前端访问。
（9）节省带宽：支持 GZIP 压缩，可以添加浏览器本地缓存的 Header 头。
（10）稳定性高：用于反向代理，宕机的概率微乎其微
四、Nginx的事件处理机制
对于一个基本的web服务器来说，事件通常有三种类型，网络事件、信号、定时器。
首先看一个请求的基本过程：建立连接—接收数据—发送数据 。再次看系统底层的操作 ：上述过程（建立连接—接收数据—发送数据）在系统底层就是读写事件。
1）如果采用阻塞调用的方式，当读写事件没有准备好时，必然不能够进行读写事件，那么久只好等待，等事件准备好了，才能进行读写事件。那么请求就会被耽搁 。阻塞调用会进入内核等待，cpu就会让出去给别人用了，对单线程的worker来说，显然不合适，当网络事 件越多时，大家都在等待呢，cpu空闲下来没人用，cpu利用率自然上不去了，更别谈高并发了 。
2）既然没有准备好阻塞调用不行，那么采用非阻塞方式。非阻塞就是，事件，马上返回EAGAIN，告诉你，事件还没准备好呢，你慌什么，过会再来吧。好吧，你过一会，再来检查一下事件，直到事件准备好了为止，在这期间，你就可以先去做其它事情，然后再来看看事 件好了没。虽然不阻塞了，但你得不时地过来检查一下事件的状态，你可以做更多的事情了，但带来的开销也是不小的
小结：非阻塞通过不断检查事件的状态来判断是否进行读写操作，这样带来的开销很大。
3）因此才有了异步非阻塞的事件处理机制。具体到系统调用就是像select/poll/epoll/kqueue这样的系统调用。他们提供了一种机制，让你可以同时监控多个事件，调用他们是阻塞的，但可以设置超时时间，在超时时间之内，如果有事件准备好了，就返回。这种机制解决了我们上面两个问题。
以epoll为例：当事件没有准备好时，就放入epoll(队列)里面。如果有事件准备好了，那么就去处理；如果事件返回的是EAGAIN，那么继续将其放入epoll里面。从而，只要有事件准备好了，我们就去处理她，只有当所有时间都没有准备好时，才在epoll里面等着。这样 ，我们就可以并发处理大量的并发了，当然，这里的并发请求，是指未处理完的请求，线程只有一个，所以同时能处理的请求当然只有一个了，只是在请求间进行不断地切换而已，切换也是因为异步事件未准备好，而主动让出的。这里的切换是没有任何代价，你可以理 解为循环处理多个准备好的事件，事实上就是这样的。
4）与多线程的比较：与多线程相比，这种事件处理方式是有很大的优势的，不需要创建线程，每个请求占用的内存也很少，没有上下文切换，事件处理非常的轻量级。并发数再多也不会导致无谓的资源浪费（上下文切换）。
小结：通过异步非阻塞的事件处理机制，Nginx实现由进程循环处理多个准备好的事件，从而实现高并发和轻量级。
五、Nginx的内部(进程)模型
ginx是以多进程的方式来工作的。nginx在启动后，会有一个master进程和多个worker进程
master进程主要用来管理worker进程：
1、接收来自外界的信号，向各worker进程发送信号。
2、监控worker进程的运行状态，当worker进程退出后(异常情况下)，会自动重新启动新的worker进程。而基本的网络事件，则是放在worker进程中来处理了。worker进程之间是对等的，一个请求，只可能在一个worker进程中处理，一个worker进程，不可能处理其它进程的请求。worker进程的个数，一般会设置与机器cpu核数一致。当我们提供80端口的http服务时，一个连接请求过来，每个进程都有可能处理这个连接。
nginx采用了异步非阻塞的方式来处理请求，也就是说，nginx是可以同时处理成千上万个请求的。
精品文章推荐阅读：
