[系统运维]05-nginx正向代理、反向代理、安全控制、负载均衡

写在开始

需要有两条虚拟机，并且上面都安装了nginx

一、 正向代理

1.1概念

正向代理，意思是一个位于客户端和原始服务器(origin server)之间的服务器，为了从原始服务器取得内容，客户端向代理发送一个请求并指定目标(原始服务器)，然后代理向原始服务器转交请求并将获得的内容返回给客户端。客户端才能使用正向代理。

我们想要需要去访问国外的某些网站，此时你会发现位于国外的某网站我们通过浏览器是没有办法访问的，此时大家可能都会用一个操作翻墙进行访问，翻墙的方式主要是找到一个可以访问国外网站的代理服务器，我们将请求发送给代理服务器，代理服务器去访问国外的网站，然后将访问到的数据传递给我们！

上述这样的代理模式称为正向代理，正向代理最大的特点是客户端非常明确要访问的服务器地址；服务器只清楚请求来自哪个代理服务器，而不清楚来自哪个具体的客户端；正向代理模式屏蔽或者隐藏了真实客户端信息。

1.2 正向代理实现

• 我自己电脑安装了两条虚拟机，分别在192.168.38.131和192.168.38.132
  
• 在192.168.38.131主机（该主机是目标服务器）上配置nginx.conf文件如下

    log_format main 'client send request=>clientIp=$remote_addr serverIp=$host';
    server {
        listen 80;
        server_name localhost;
        access_log logs/access.log main;
        location /{
            root html;
            index lss.html;
        }

    }

• 代理服务器设置：-在192.168.38.132主机（该主机是代理服务器）上配置nginx.conf文件如下

    server {
        listen 82;
        server_name localhost;

        location /{
             proxy_pass http://$host$request_uri;
        }

    }

• 做如下配置
  
• 在浏览器重新访问，查看是否走了代理
  
• 示例过后，要把上述操作还原，因为会连不上互联网。

通过对比，上下两次的日志记录，会发现虽然我们是客户端访问服务端，但是如何使用了代理，那么服务端能看到的只是代理发送过去的请求，这样的话，就使用Nginx实现了正向代理的设置。

但是Nginx正向代理，在实际的应用中不是特别多，所以我们简单了解下，接下来我们继续学习Nginx的反向代理，这是Nginx比较重要的一个功能。

二、 反向代理实现

客户端对代理是无感知的，因为客户端不需要配置任何配置参数就可以访问，客户端只需要将请求发送到反向代理服务器，由反向代理服务器去请求目标服务器获取数据后，再返回给客户端，此时反向代理服务器和目录服务器对外就是一个服务器，暴露的是代理代理服务器地址，隐藏了真实服务器IP地址。
Nginx反向代理模块的指令是由ngx_http_proxy_module模块进行解析，该模块在安装Nginx的时候已经自己加装到Nginx中了，接下来我们把反向代理中的常用指令一一介绍下：

proxy_pass
proxy_set_header
proxy_redirect

1. proxy_pass

该指令用来设置被代理服务器地址，可以是主机名称、IP地址加端口号形式。

URL:为要设置的被代理服务器地址，包含传输协议(http,https://)、主机名称或IP地址加端口号、URI等要素。
示例

• 准备两台虚拟机分别在192.168.38.131和192.168.38.132,两个虚拟机都安装了nginx。以192.168.38.132作为代理服务器，192.168.38.131作为目标服务器。
  

• 192.168.38.131作为目标服务器，在/usr/local/nginx/html/下新建znn.html内容如下：
  

• 192.168.38.132作为代理服务器，在nginx.conf配置如下：
  

• 192.168.38.131作为目标服务器，在nginx.conf配置如下：
  

• 该配置的意思是，当我在浏览器访问代理服务器：http://192.168.38.132:82/ 时，代理服务器通过proxy_pass http://192.168.38.131上面。
  

• 注意一点是上面代理服务器的server块中的location中的proxy_pass http://192.168.38.131 后面没加“/”，如果加了斜杠呢，也可以正常访问：

• 

• 修改192.168.38.132代理服务器，在nginx.conf配置如下，主要在server块中的location块后面加了目录。并将上一步在proxy_pass http://192.168.38.131/，后面的/给去掉，目标服务器不做任何修改。
  

• 修改192.168.38.132代理服务器，在nginx.conf配置如下，上一步在proxy_pass http://192.168.38.131，后面加上/，目标服务器不做任何修改。
  
  总结

  server {
  	listen 80;
  	server_name localhost;
  	location /{
  		#proxy_pass http://192.168.200.146;
  		proxy_pass http://192.168.200.146/;
  	}
  }
  当客户端访问 http://localhost/index.html,效果是一样的
  server{
  	listen 80;
  	server_name localhost;
  	location /server{
  		#proxy_pass http://192.168.200.146;
  		proxy_pass http://192.168.200.146/;
  	}
  }
  当客户端访问 http://localhost/server/index.html
  这个时候，第一个proxy_pass就变成了http://localhost/server/index.html
  第二个proxy_pass就变成了http://localhost/index.html效果就不一样了。
  

2. proxy_set_header

该指令可以更改Nginx服务器接收到的客户端请求的请求头信息，然后将新的请求头发送给被代理的服务器即目标服务器。

需要注意的是，如果想要看到结果，必须在被代理的服务器上来获取添加的头信息。

被代理服务器（目标服务器）[192.168.38.131]

$http_ + proxy_set_header的key，即可取到对应的值。
代理服务器[192.168.38.132]

浏览器访问测试

3. proxy_redirect

当上游服务器（被代理服务器）返回的响应是重定向或刷新请求（如HTTP响应码是301或者302）时，proxy_redirect可以重设返回的响应头中的location头域或refresh头域的值。

location响应头:用于重定向接受者到一个新的URI地址。Location通常不是直接设置的，而是通过HttpServletResponse的sendRedirect方法，该方法同时设置状态代码为302。
Refresh:表示浏览器应该在多少时间之后刷新文档，以秒计。除了刷新当前文档之外，你还可以通过setHeader(“Refresh”, “5; URL=http://host/path”)让浏览器读取指定的页面。

注意Refresh的意义是"N秒之后刷新本页面或访问指定页面"，而不是"每隔N秒刷新本页面或访问指定页面"。

为什么要用该指令?

目标服务器[192.168.38.131]

代理服务器[192.168.38.133]

• 通过浏览器进行访问
  
• 可以通过curl命令来查看上述响应location的值
  
• 通过上面的分析，可以看到这样在目标服务器重定向之后，浏览器的任务栏暴露了目标服务器的地址，这样是不允许的，如何解决，就使用到了：proxy_redirect

• 解决上述问题，在代理服务器上一步的结果中，新加下面的配置
  
  该指令的几组选项

1.proxy_redirect redirect replacement;
redirect：location的值
replacement：要替换的值

2.proxy_redirect default;
default ：将location块的uri变量作为replacement；将proxy_pass变量作为redirect进行替换。下面两者是等价
的。 proxy_pass中使用了变量，则不能使用default
location /one/ {
    proxy_pass     http://upstream:port/two/;
    proxy_redirect default;
location /one/ {
    proxy_pass     http://upstream:port/two/;
    proxy_redirect http://upstream:port/two/ /one/;
    
3. proxy_redirect off;
   关闭proxy_redirect的功能。

4. Nginx反向代理实战

服务器1,2,3存在两种情况
第一种情况：三台服务器的内容不一样。
第二种情况：三台服务器的内容都一样。

如果服务器1、服务器2和服务器3的内容不一样，那我们可以根据用户请求来分发到不同的服务器。

2. 如果服务器1、服务器2和服务器3的内容是一样的，该如何处理?看下面的负载均衡讲解。

三、 Nginx的安全控制

关于web服务器的安全是比较大的一个话题，里面所涉及的内容很多，Nginx反向代理是如何来提升web服务器的安全呢？–安全隔离。
什么是安全隔离
通过代理分开了客户端到应用程序服务器端的连接，实现了安全措施。在反向代理之前设置防火墙，仅留一个入口供代理服务器访问。

3.1 如何使用SSL对流量进行加密

翻译成大家能熟悉的说法就是将我们常用的http请求转变成https请求，那么这两个之间的区别简单的来说两个都是HTTP协议，只不过https是身披SSL外壳的http。
HTTPS是一种通过计算机网络进行安全通信的传输协议。它经由HTTP进行通信，利用SSL/TLS建立全通信，加密数据包，确保数据的安全性。
SSL(Secure Sockets Layer)安全套接层。
TLS(Transport Layer Security)传输层安全。
上述这两个是为网络通信提供安全及数据完整性的一种安全协议，TLS和SSL在传输层和应用层对网络连接进行加密。

总结来说为什么要使用https:

http协议是明文传输数据，存在安全问题，而https是加密传输，相当于http+ssl，并且可以防止流量劫持。

Nginx要想使用SSL，需要满足一个条件即需要添加一个模块--with-http_ssl_module,而该模块在编译的过程中又需要OpenSSL的支持

nginx添加SSL的支持

完成--with-http_ssl_module模块的增量添加。

1. 拷贝nginx之前的配置信息
   
2. 将原有/usr/local/nginx/sbin/nginx进行备份
   
3. 回到nginx的安装目录
   
4. 在nginx安装目录，执行如下命令
   
5. 执行make命令
   
6. 执行命令cd objs看到下面的nginx二进制可执行文件。

7.执行命令cp nginx /usr/local/nginx/sbin把这个二进制可执行文件移动到sbin下

7. cd ..往上跳一级来到nginx的安装目录。执行make upgrade

8 执行nginx -V查看模块with-http_ssl_module 是否安装成功。

3.2 Nginx的SSL相关指令

因为刚才我们介绍过该模块的指令都是通过ngx_http_ssl_module模块来解析的。

1. ssl

ssl:该指令用来在指定的服务器开启HTTPS,可以使用 listen 443 ssl,后面这种方式更通用些。

示例：

server{
	listen 443 ssl;
}

2. ssl_certificate

ssl_certificate:为当前这个虚拟主机指定一个带有PEM格式证书的证书。

3. ssl_certificate_key

该指令用来指定PEM secret key文件的路径

4.ssl_session_cache

该指令用来配置用于SSL会话的缓存

off:禁用会话缓存，客户端不得重复使用会话

none:禁止使用会话缓存，客户端可以重复使用，但是并没有在缓存中存储会话参数

builtin:内置OpenSSL缓存，仅在一个工作进程中使用。

shared:所有工作进程之间共享缓存，缓存的相关信息用name和size来指定

5.ssl_session_timeout

开启SSL会话功能后，设置客户端能够反复使用储存在缓存中的会话参数时间。

6. ssl_ciphers

指出允许的密码，密码指定为OpenSSL支持的格式

可以使用openssl ciphers查看openssl支持的格式。

7.ssl_prefer_server_ciphers

该指令指定是否服务器密码优先客户端密码

生成证书
方式一：使用阿里云/腾讯云等第三方服务进行购买（不再给出）。
方式二：使用openssl生成证书。
先要确认当前系统是否有安装openssl

openssl version

安装下面的命令进行生成

mkdir /root/cert
cd /root/cert
openssl genrsa -des3 -out server.key 1024
openssl req -new -key server.key -out server.csr
cp server.key server.key.org
openssl rsa -in server.key.org -out server.key
openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

• 后面所有命令让输入，随便输入即可，没有校验。
  
• 最后查看生成的证书
  
  开启SSL实例
  未采用http时访问浏览器地址栏前面有不安全的字样。使用https时发现不能访问。
  
  如何使用https进行访问呢？
• 打开nginx做如下配置
  
• 发现可以通过https进行访问了。但是出现了上面的情况，因为生成的证书，是本地生成的，没有经过第三方的认证。做如下操作继续访问。
• 
  可以使用阿里云或腾讯云购买域名的时候生成ssl证书。配置如下：
  
• 通过浏览器访问https//nginx521.cn，发现没有了不安全的字样。
  
• 但是有一个问题，我们需要手动的在前面加上https,但像我们访问百度时，也没有加https,直接输入的www.baidu.com就能访问了，而我们的还要手动加上https，解决此问题就要用到前面讲过得rewrite命令了。

• 再次通过浏览器访问直接输入www.nginx521.cn即可进行https访问了。
  

四、 反向代理系统优化

反向代理值Buffer和Cache
Buffer翻译过来是"缓冲"，Cache翻译过来是"缓存"。

总结下：

相同点:
两种方式都是用来提供IO吞吐效率，都是用来提升Nginx代理的性能。
不同点:
缓冲主要用来解决不同设备之间数据传递速度不一致导致的性能低的问题，缓冲中的数据一旦此次操作完成后，就可以删除。
缓存主要是备份，将被代理服务器的数据缓存一份到代理服务器，这样的话，客户端再次获取相同数据的时候，就只需要从代理服务器上获取，效率较高，缓存中的数据可以重复使用，只有满足特定条件才会删除.

Proxy Buffer相关指令

1. proxy_buffering

该指令用来开启或者关闭代理服务器的缓冲区

2. proxy_buffers

该指令用来指定单个连接从代理服务器读取响应的缓存区的个数和大小。

number:缓冲区的个数
size:每个缓冲区的大小，缓冲区的总大小就是number*size

3.proxy_buffer_size

该指令用来设置从被代理服务器获取的第一部分响应数据的大小。保持与proxy_buffers中的size一致即可，当然也可以更小。

4. proxy_busy_buffers_size

该指令用来限制同时处于BUSY状态的缓冲总大小。

5. proxy_temp_path

当缓冲区存满后，仍未被Nginx服务器完全接受，响应数据就会被临时存放在磁盘文件上，该指令设置文件路径

注意path最多设置三层。

6. proxy_temp_file_write_size

该指令用来设置磁盘上缓冲文件的大小。

通用网站的配置

proxy_buffering on;
proxy_buffer_size 4 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;

根据项目的具体内容进行相应的调节。

五、 nginx负载均衡

5.1 负载均衡概述

早期的网站流量和业务功能都比较简单，单台服务器足以满足基本的需求，但是随着互联网的发展，业务流量越来越大并且业务逻辑也跟着越来越复杂，单台服务器的性能及单点故障问题就凸显出来了，因此需要多台服务器进行性能的水平扩展及避免单点故障出现。那么如何将不同用户的请求流量分发到不同的服务器上呢？

5.2 负载均衡的原理及处理流程

系统的扩展可以分为纵向扩展和横向扩展。
纵向扩展是从单机的角度出发，通过增加系统的硬件处理能力来提升服务器的处理能力。更换cpu、增加内存条等，但是纵向扩展到一定程度就会达到瓶颈。
横向扩展是通过添加机器来满足大型网站服务的处理能力。

这里面涉及到两个重要的角色分别是"应用集群"和"负载均衡器"。
应用集群：将同一应用部署到多台机器上，组成处理集群，接收负载均衡设备分发的请求，进行处理并返回响应的数据。
负载均衡器:将用户访问的请求根据对应的负载均衡算法，分发到集群中的一台服务器进行处理。

5.3 负载均衡的作用

1. 解决服务器的高并发压力，提高应用程序的处理性能。
2. 提供故障转移，实现高可用。
3. 通过添加或减少服务器数量，增强网站的可扩展性。
4. 在负载均衡器上进行过滤，可以提高系统的安全性。

5.4 负载均衡常用的处理方式

方式一：用户手动选择

这种方式比较原始，只要实现的方式就是在网站主页上面提供不同线路、不同服务器链接方式，让用户来选择自己访问的具体服务器，来实现负载均衡。

方式二：DNS轮询方式

DNS
域名系统（服务）协议（DNS）是一种分布式网络目录服务，主要用于域名与 IP 地址的相互转换。
大多域名注册商都支持对同一个主机名添加多条A记录（即同一个域名绑定多个ip），这就是DNS轮询，DNS服务器将解析请求按照A记录的顺序，随机分配到不同的IP上，这样就能完成简单的负载均衡。DNS轮询的成本非常低，在一些不重要的服务器，被经常使用。

如下是我们为某一个域名添加的IP地址，用2台服务器来做负载均衡。

验证：使用如下域名访问时会随机选择一台服务器。

ping www.nginx521.com

需要清空DNS缓存，使用如下命令

ipconfig/flushdns

发现使用DNS来实现轮询，不需要投入过多的成本，虽然DNS轮询成本低廉，但是DNS负载均衡存在明显的缺点。

1.可靠性低
假设一个域名DNS轮询多台服务器，如果其中的一台服务器发生故障，那么所有的访问该服务器的请求将不会有所回应，即使你将该服务器的IP从DNS中去掉，但是由于各大宽带接入商将众多的DNS存放在缓存中，以节省访问时间，导致DNS不会实时更新。所以DNS轮流上一定程度上解决了负载均衡问题，但是却存在可靠性不高的缺点。

2.负载均衡不均衡
DNS负载均衡采用的是简单的轮询负载算法，不能区分服务器的差异，不能反映服务器的当前运行状态，不能做到为性能好的服务器多分配请求，另外本地计算机也会缓存已经解析的域名到IP地址的映射，这也会导致使用该DNS服务器的用户在一定时间内访问的是同一台Web服务器，从而引发Web服务器减的负载不均衡。
负载不均衡则会导致某几台服务器负荷很低，而另外几台服务器负荷确很高，处理请求的速度慢，配置高的服务器分配到的请求少，而配置低的服务器分配到的请求多。

方式三：四/七层负载均衡

介绍四/七层负载均衡之前，我们先了解一个概念，OSI(open system interconnection),叫开放式系统互联模型，这个是由国际标准化组织ISO指定的一个不基于具体机型、操作系统或公司的网络体系结构。该模型将网络通信的工作分为七层。

应用层：为应用程序提供网络服务。
表示层：对数据进行格式化、编码、加密、压缩等操作。
会话层：建立、维护、管理会话连接。
传输层：建立、维护、管理端到端的连接，常见的有TCP/UDP。
网络层：IP寻址和路由选择
数据链路层：控制网络层与物理层之间的通信。
物理层：比特流传输。
可以参考这篇文章网络传输模型

所谓四层负载均衡指的是OSI七层模型中的传输层，主要是基于IP+PORT的负载均衡

实现四层负载均衡的方式：
硬件：F5 BIG-IP、Radware等
软件：LVS、Nginx、Hayproxy等

所谓的七层负载均衡指的是在应用层，主要是基于虚拟的URL或主机IP的负载均衡

实现七层负载均衡的方式：
软件：Nginx、Hayproxy等

四层和七层负载均衡的区别

四层负载均衡数据包是在底层就进行了分发，而七层负载均衡数据包则在最顶端进行分发，所以四层负载均衡的效率比七层负载均衡的要高。
四层负载均衡不识别域名，而七层负载均衡识别域名。

除了四层和七层负载之外其实还有二层、三层负载均衡，二层是在数据链路层基于mac地址来实现负载均衡，三层是在网络层一般采用虚拟IP地址的方式实现负载均衡。
实际环境采用的模式

四层负载(LVS)+七层负载(Nginx)

Nginx七层负载均衡

Nginx要实现七层负载均衡需要用到proxy_pass代理模块配置。Nginx默认安装支持这个模块，我们不需要再做任何处理。Nginx的负载均衡是在Nginx的反向代理基础上把用户的请求根据指定的算法分发到一组【upstream虚拟服务池】。

1.Nginx七层负载均衡的指令

1.upstream指令

该指令是用来定义一组服务器，它们可以是监听不同端口的服务器，并且也可以是同时监听TCP和Unix socket的服务器。服务器可以指定不同的权重，默认为1。

2.server指令

该指令用来指定后端服务器的名称和一些参数，可以使用域名、IP、端口或者unix socket。与之前的server指令不一样。

2.Nginx七层负载均衡的实现流程

老样子，由于没有多余的服务器，我们以端口做区分。准备两台虚拟机,ip地址分别为：
192.168.38.131以及192.168.38.133。通过访问主机192.168.38.131，将请求转发到服务器集群中。

• 服务器集群(192.168.38.133)做如下配置
  
• 负载均衡器192.168.38.131做如下配置
  
• 通过浏览器访问
  

5.5 负载均衡状态

1. down

down:将该服务器标记为永久不可用，那么该代理服务器将不参与负载均衡。

• 示例：在192.168.38.131做如下配置
  
• 通过浏览器访问：发现使用谷歌访问，看着不会访问到8083的端口，这是由于谷歌浏览器的问题，我们换一种方式。
  
• 可以看到负载均衡只在192.168.38.133:8082与8083之间轮询。也可以通过edge浏览器
  
  该状态一般会对需要停机维护的服务器进行设置。

2. backup

backup:将该服务器标记为备份服务器，当主服务器不可用时，将用来传递请求。

• 此时只能访问8083端口的服务器
  

此时需要将8083端口的访问禁止掉来模拟下唯一能对外提供访问的服务宕机以后，backup的备份服务器就要开始对外提供服务，此时为了测试验证，我们需要使用防火墙来进行拦截。

介绍一个工具firewall-cmd,该工具是Linux提供的专门用来操作firewall的。

• 查询防火墙中指定的端口是否开发

  firewall-cmd --query-port=9001/tcp
  

• 如何开发一个指定的端口

  	firewall-cmd --permanent --add-port=8083/tcp
  

• 批量添加开放端口 设置的是一个范围同样适用于remove

  	firewall-cmd --permanent --add-port=8082-8083/tcp
  

• 如何移除一个指定的端口

  	firewall-cmd --permanent --remove-port=8083/tcp
  

• 执行完成上面的命令，都需要执行下面的命令重新加载

      firewall-cmd --reload
  

• 查看开启的端口和服务

  	firewall-cmd --permanent --list-ports
  

  其中
  --permanent表示为持久
  --add-port表示添加指定端口
  --remove-port表示移除指定端口

• 将192.168.38.133:8083端口添加到防火墙，查看192.168.38.133备份是否生效。
  

• 通过浏览器访问
  

3. max_conns

max_conns=number:用来设置代理服务器同时活动链接的最大数量，默认为0，表示不限制，使用该配置可以根据后端服务器处理请求的并发量来进行设置，防止后端服务器被压垮。–无法演示

4. max_fails和fail_timeout

max_fails=number:设置允许请求代理服务器失败的次数，默认为1。
fail_timeout=time:设置经过max_fails失败后，服务暂停的时间，默认是10秒。上面两个集合使用，就像spring-cloud中的hystirx

• 192.138.38.131做如下配置
  
• 8081已经不可用，8082是备份的，通过关闭`8083``端口在防火墙的打开关闭来演示8083的请求失败。首先将8083的端口放开，让浏览器能访问。
  
  
• 然后在192.168.38.133上的防火墙关闭8083端口，此时刷新页面连续刷新3次，因为3次都失败之后，负载均衡才不会将请求轮询到8083。然后在15s之内在防火请中再次放行端口，一直刷新页面，到15s结束后，发现可以访问到8083了。
  

5.6 负载均衡策略

介绍完Nginx负载均衡的相关指令后，我们已经能实现将用户的请求分发到不同的服务器上，那么除了采用默认的分配方式以外，我们还能采用什么样的负载算法?

Nginx的upstream支持如下六种方式的分配算法，分别是:

1. 轮询

是upstream模块负载均衡默认的策略。每个请求会按时间顺序逐个分配到不同的后端服务器。轮询不需要额外的配置。

2. weight加权[加权轮询]

weight=number:用来设置服务器的权重，默认为1，权重数据越大，被分配到请求的几率越大；该权重值，主要是针对实际工作环境中不同的后端服务器硬件配置进行调整的，所有此策略比较适合服务器的硬件配置差别比较大的情况。

3. ip_hash

当对后端的多台动态应用服务器做负载均衡时，ip_hash指令能够将某个客户端IP的请求通过哈希算法定位到同一台后端服务器上。这样，当来自某一个IP的用户在后端Web服务器A上登录后，在访问该站点的其他URL，能保证其访问的还是后端web服务器A。

• 做如下配置

  

• 可以解决session问题，若不使用ip_hash的话，第一次请求时由于负载均衡分发到某一台进行了登录操作，产生session，当第二次请求时又分发到别的服务器，这个服务器没session信息，又要再次登录。。。所以使用ip_hash，会将同一个ip固定访问某一个后台服务器，这样就解决了session问题。开发中一般使用redis来解决登录问题。
  

  需要额外多说一点的是使用ip_hash指令无法保证后端服务器的负载均衡，可能导致有些后端服务器接收到的请求多，有些后端服务器接收的请求少，而且设置后端服务器权重等方法将不起作用。

4. least_conn

最少连接，把请求转发给连接数较少的后端服务器。轮询算法是把请求平均的转发给各个后端，使它们的负载大致相同；但是，有些请求占用的时间很长，会导致其所在的后端负载较高。这种情况下，least_conn这种方式就可以达到更好的负载均衡效果。

5. url_hash

按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，要配合缓存命中来使用。同一个资源多次请求，可能会到达不同的服务器上，导致不必要的多次下载，缓存命中率不高，以及一些资源时间的浪费。而使用url_hash，可以使得同一个url（也就是同一个资源请求）会到达同一台服务器，一旦缓存住了资源，再此收到请求，就可以从缓存中读取。

 upstream backend{
        hash &request_uri;
        server 192.168.38.133:8081;
        server 192.168.38.133:8082;
        server 192.168.38.133:8083;

   }
    server{
        listen 8080;
        server_name localhost;
        location /{
            proxy_pass http://backend;
        }
  }

6. fair

fair采用的不是内建负载均衡使用的轮换的均衡算法，而是可以根据页面大小、加载时间长短智能的进行负载均衡。那么如何使用第三方模块的fair负载均衡策略。


但是如果直接使用会报错，因为fair属于第三方模块实现的负载均衡。需要添加nginx-upstream-fair,如何添加对应的模块:

1. 下载nginx-upstream-fair
   fair下载

2. 将下载的文件上传到服务器并进行解压缩

   unzip nginx-upstream-fair-master.zip
   

3. 重命名资源

   mv nginx-upstream-fair-master fair
   

4. 使用nginx-V查看已有的模块
   

   --with-http_gzip_static_module --with-http_ssl_module
   

5. 将 /usr/locang/nginx/sbin/下的nginx二进制可执行文件备份

   mv nginx nginx.old
   

6. 使用./configure命令将资源添加到Nginx模块中，不要忘了第四步的的模块。

    ./configure --with-http_gzip_static_module --with-http_ssl_module --add-module=/opt/module/fair
   

7. 编译

   make
   

8. 编译可能会出现如下错误，ngx_http_upstream_srv_conf_t结构中缺少default_port
   

9. 解决方案：
   在Nginx的源码中 src/http/ngx_http_upstream.h,找到ngx_http_upstream_srv_conf_s，在模块中添加添加default_port属性

   in_port_t	   default_port
   

   

10. 然后执行make

11. 将安装目录下的objs中的nginx拷贝到sbin目录

    cd objs
    cp nginx /usr/local/nginx/sbin
    

    

12. 更新Nginx

    cd ../
    make upgrade
    

13. nginx -s reload不报错了，浏览器也能访问，说明添加成功了。

上面介绍了Nginx常用的负载均衡的策略，有人说是5种，是把轮询和加权轮询归为一种（其实轮询就是weight=1的情况，如果不显示的加的话，默认会加上），也有人说是6种。那么在咱们以后的开发中到底使用哪种，这个需要根据实际项目的应用场景来决定的。

5.7 负载均衡案例

案例一：对所有请求实现一般轮询规则的负载均衡

upstream backend{
	server 192.168.38.133:8081;
	server 192.168.38.133:8082;
	server 192.168.38.133:8083;
}
server {
	listen 8080;
	server_name localhost;
	location /{
		proxy_pass http://backend;
	}
}

案例二：对所有请求实现加权轮询规则的负载均衡

upstream backend{
	server 192.168.200.146:9001 weight=7;
	server 192.168.200.146:9002 weight=5;
	server 192.168.200.146:9003 weight=3;
}
server {
	listen 8083;
	server_name localhost;
	location /{
		proxy_pass http://backend;
	}
}

案例三：对特定资源实现负载均衡

upstream videobackend{
	server 192.168.200.146:9001;
	server 192.168.200.146:9002;
}
upstream filebackend{
	server 192.168.200.146:9003;
	server 192.168.200.146:9004;
}
server {
	listen 8084;
	server_name localhost;
	location /video/ {
		proxy_pass http://videobackend;
	}
	location /file/ {
		proxy_pass http://filebackend;
	}
}

案例四：对不同域名实现负载均衡

upstream lss{
	server 192.168.200.146:9001;
	server 192.168.200.146:9002;
}
upstream lzz{
	server 192.168.200.146:9003;
	server 192.168.200.146:9004;
}
server {
	listen	8085;
	server_name www.lss.cn;
	location / {
		proxy_pass http://lss;
	}
}
server {
	listen	8086;
	server_name www.lzz.cn;
	location / {
		proxy_pass http://lzz;
	}
}

案例五：实现带有URL重写的负载均衡

upstream backend{
	server 192.168.200.146:9001;
	server 192.168.200.146:9002;
	server 192.168.200.146:9003;
}
server {
	listen	80;
	server_name localhost;
	location /file/ {
		rewrite ^(/file/.*) /server/$1 last;
	}
	location / {
		proxy_pass http://backend;
	}
}

5.7 Nginx四层负载均衡

之前的都是七层负载均衡。
Nginx在1.9之后，增加了一个stream模块，用来实现四层协议的转发、代理、负载均衡等。stream模块的用法跟http的用法类似，允许我们配置一组TCP或者UDP等协议的监听，然后通过proxy_pass来转发我们的请求，通过upstream添加多个后端服务，实现负载均衡。

四层协议负载均衡的实现，一般都会用到LVS、HAProxy、F5等，要么很贵要么配置很麻烦，而Nginx的配置相对来说更简单，更能快速完成工作。

1. 添加stream模块的支持

Nginx默认是没有编译这个模块的，需要使用到stream模块，那么需要在编译的时候加上--with-stream。

完成添加--with-stream的实现步骤:

》将原有/usr/local/nginx/sbin/nginx进行备份
》拷贝nginx之前的配置信息
》在nginx的安装源码进行配置指定对应模块  ./configure --with-stream
》通过make模板进行编译
》将objs下面的nginx移动到/usr/local/nginx/sbin下
》在源码目录下执行  make upgrade进行升级，这个可以实现不停机添加新模块的功能

2. Nginx四层负载均衡的指令

1.stream指令

该指令提供在其中指定流服务器指令的配置文件上下文。和http指令同级。

2.upstream指令

该指令和http的upstream指令是类似的。

3. 四层负载均衡的案例

需求分析
通过192.168.38.131上面的nginx，负载均衡访问192.168.38.133上面的两条redis和一台tomcat。；

实现步骤
(1)准备Redis服务器,在一条服务器上准备三个Redis，端口分别是6379,6378

1. 上传redis的安装包
   

2. 将安装包进行解压

   tar -zxvf redis-7.0.4.tar.gz
   

3. 进入redis安装包

   cd redis-7.0.4/
   

4. 使用make和install进行编译和安装 。prefix指定安装目录。

   make PREFIX=/usr/local/redis/redis01 install
   

5. 拷贝redis配置文件redis.conf到/usr/local/redis/redis01/bin目录中

   cp redis.conf	/usr/local/redis/redis01/
   

6. 修改/usr/local/redis/redis01/bin下的redis.conf配置文件

   port  6379      #redis的端口
   daemonize yes   #后台启动redis
   

   

7. 将redis01复制一份为redis02

   cd /usr/local/redis
   cp -r redis01 redis02
   

8. 将redis02文件文件夹中的redis.conf进行修改

   port  6378      #redis的端口
   daemonize yes   #后台启动redis
   

9. 分别启动，即可获取两个redis，并查看

   ps -ef | grep redis
   

   
   

10. redis在windows下连接先下载Windows版

11. 在windows下的redis目录执行cmd命令

12. 输入redis-cli -h 192.168.38.133 -p 6379 来通过windows连接远程服务器上的redis。

 -h redis所在的主机
 -port 端口号

13 .发现都无法连接成功，打开redis所在服务器，修改redis.conf中的bind为0.0.0.0配置如下。修改前先使用kill命令关闭redis。

修改第一台redis和第二台redis，方式都一样
14. 重新启动redis

15. windows下cmd从新连接（若还连不上，防火墙要放行端口）
若报以下错误则


redis认为远程连接不安全，所以阻止你对redis进行操作
解决办法：下面的两种方式都是修改redis.conf文件
方式一：关闭保护模式（两条redis更改一样，这里以一台 示例）

重新启动redis访问。

windows下的cmd再次访问。

方式二：给redis设置登录密码（建议这种）
修改前将之前的protected-mode还改为on，恢复为原样，然后通过设置添加密码的方式。

重新启动redis，windows连接如下

(2)准备Tomcat服务器，上传到192.168.38.133上。

解压这后，进入到bin目录下执行./startup.sh启动Tomcat

• 根据线程号查询正在运行的程序的port(端口号) netstat -anop | grep pid(程序的线程号)
  

通过浏览器访问成功代表Tomcat已启动。

(2)192.168.38.131作为负载均衡器，在nginx.conf做如下配置。

events {   
    worker_connections  1024;
}             
# stream与http同级
stream {
        upstream redisbackend {
                server 192.168.38.133:6379;
                server 192.168.38.133:6378;
        }
        upstream tomcatbackend {
                server 192.168.38.133:8080; 
        } 
        server {
                listen  81;
                proxy_pass redisbackend;
        }
        server {
                listen  82;
                proxy_pass tomcatbackend;
        }
}

注意该段配置使用nginx -s reload若不生效，则执行nginx -s stop、nginx -s start重启nginx

• 通过访问192.168.38.131上的81端口，可以看到在不停的轮询连接到192.168.38.133上面的两台Redis服务器。
  

• 通过访问192.168.38.131上的82端口，访问192.168.38.133上面的Tomcat服务器。