java架构之路-（nginx使用详解）nginx的反向代理和优化配置

　　书接上回说，nginx我们学会了简单的配置。那么我今天来聊一下，我们ngxin的一些优化配置（我不是很懂，不敢谈高级配置）。我先来看一下nginx的好处和正向代理。

nginx的好处

1、可以高并发连接,官方测试Nginx能够支撑5万并发连接，实际生产环境中可以支撑2~4万并发连接数。他的NIO模式上个博客提到过，这里不再赘述了。

2、内存消耗少，Nginx+PHP（FastCGI）服务器，在3万并发连接下，开启10个Nginx进程消耗150MB内存，15MB*10=150MB，开启的64个PHP-CGI进程消耗1280内存，20MB*64=1280MB，加上系统自身消耗的内存，总共消耗不到2GB的内存。

如果服务器的内存比较小，完全可以只开启25个PHP-CGI进程，这样PHP-CGI消耗的总内存数才500MB。

3、成本低廉，开源软件，不需要任何成本。

4、配置文件非常简单，网络和程序一样通俗易懂，即使，非专用系统管理员也能看懂。

5、支持Rewrite重写，能够根据域名、URL的不同，将http请求分到不同的后端服务器群组。

6、内置的健康检查功能如果，NginxProxy后端的某台Web服务器宕机了，不会影响前端的访问。（这个后面会给予详细的配置和说明）

7、节省带宽，支持GZIP压缩，可以添加浏览器本地缓存的Header头。

8、稳定性高，用于反向代理，宕机的概率微乎其微。

9、支持热部署，Nginx支持热部署，它的自动特别容易，并且，几乎可以7天*24小时不间断的运行，即使，运行数个月也不需要重新启动，还能够在不间断服务的情况下，对软件版本进行升级。

说完了好处，我们来谈谈正向代理和反向代理的区别。

其实这个玩意挺不好解释的，但是一定注意几点，他俩在nginx的配置是一样的。并且不要说nginx服务器和目标服务器不在一起就是反向代理。

我们以中间商赚差价为例。

我们要去市场买肉（客户端）。这里有有一个肉联厂（真正的服务端）。我们心知肚明吧的知道菜市场肉贩子的肉是从肉联厂进货的。（肉贩子是代理端）。

我们从肉贩子手里买了肉。可以忽略这句话（这不废话吗，下面反正代理也是这样的）。关键差别在于肉联厂只知道把肉给了肉贩子，并不知道谁真正买走了他的肉，这就是正向代理。

一般用于爬虫和VPN。

还是买肉的例子。

我们要去市场买肉（客户端）。这里有有一个肉联厂（真正的服务端）。我们从肉贩子手里买了肉。关键差别在于我们并不知道肉贩子的肉是从哪个肉联厂购进的肉。（肉贩子是代理端）。

这就是反向代理，可能他们三个都认识，但是并不能确认买卖关系。

一般用于负载均衡。

我们先来看一下如何来设置负载均衡。

反正代理的负责均衡一般是轮询，权重（百分比），IP_hash，URL_hash，最小访问等算法。

反向代理相关参数：

　　proxy_pass：#服务名称（地址）

　　proxy_redirect on/off：#是否重定向

　　proxy_set_header Host $host：#传Header参数至后端服务

　　proxy_set_header X-Forwared-For $remote_addr：#传Header参数至后端服务

　　proxy_connent_timeout 90 # 连接代理服务器超时时间

　　proxy_send_timeout 90 #请求发送最大时间，默认单位秒

　　proxy_read_timeout 90 # 读取请求最大时间，默认单位秒

更多参数配置参考官网，地址http://nginx.org/en/docs/http/ngx_http_proxy_module.html。里面超详细的。

我先来配置一个最简单的反向代理。

upstream和server是同级别的，不要放置在server内部。

如果内部加入weight参数，则表示权重寻址.

表示访问两次8002，访问一次8001。循环下去。

如果其中一个服务宕机了，这时nginx会不在分发请求到那个服务上，当服务恢复，nginx会自动监控到服务启动了，会再次发送服务到该服务。

这里说两个配置，fail_timeout和slow_start。fail_timeout表示服务请求超过多长时间，就认为该服气宕机了，slow_start表示继续监控该服务多长时间，如果正常则认为服务已恢复正常。

配置如图：

注意slow_start参数不能与 hash，ip_hash和随机 负载平衡方法一起使用，官网是这样说的，但是我这一直说slow_start是无效参数。

   backup为备用服务，就是我们当前有任何一台服务器处于正常状态，请求不会分发到backup服务器上。除非所有服务器全部宕机，请求才会分发到backup上。

max_conns：允许最大连接数。

可以调节的参数还有很多，我们可以去官网查看，下面我来说一下简单的优化配置。

当我们要做大并发时，我们优先的想到的就是缓存，我们应该把静态的文件缓存下来，其实我想象中的架构可以是这样的....

这样我们可以做到请求的分发，然后把静态的JS，CSS文件分离出来，不至于让这些静态的文件占用我们的网络带宽，那么我们来看一下nginx是如何做缓存的吧。

用管理员启动，你会看到你访问以后会留下文件夹，里面是一个看不懂的文件，是一份缓存文件，我们简单说一下上面的配置都是什么意思。

proxy_cache_path声明配置块，第一个参数是路径，要和你启动的账号权限保持一致啊。不然没法写入的，levels是保存的目录等级，我们看到最后生产的文件是一个MD5的文件。1：2就是说明一级目录取文件名的最后一位数，2代理下级目录是文件名的2-3位的名字。

keys_zone=名称：文件大小，要和下面proxy_cache的名字保持一致。incative是保存的天数。max_sizes是保存的最大单位。location内部的分别是proxy_cache缓存名称，proxy_cache_key以url来MD5进行计算。如果匹配直接取缓存。

proxy_cachr_valid代表状态码为200 304时进行保存，保存12小时。

优化扩展：

我们说过，我们可以启动多个work进程，每个work都是运行在一个单独的cpu上，但是他们的访问cpu完全是随机的，可能发生cpu争抢消耗时间，我们可以采用绑定CPU的方式来解决这个问题。

参数work_cpu_affinity 0001 0010 0100 1000;这样的配置使我们启动了四个work，就是用1来占位绑定cpu。

尽量避免使用IP_hash来做配置，IP_hash只能分发到同一个外网地址的请求，很多用路由交换机代理的内网IP，并不使用IP_hash算法，会造成单服务器大量请求，不能达到均衡的目的。

nginx我们今天就聊到这里，还有很多深入的优化，官网写的很详细，大家可以自己去尝试。java开发范围的，这些我觉得差不多可以了。可以慢慢深入研究。

最进弄了一个公众号，小菜技术，欢迎大家的加入