负载均衡：将四层或者七层的请求分配到多台后端的服务器上。

从而分担整个业务的负载。提高系统的稳定性，也可以提高高可用（备灾，其中一台后端服务器如果发生故障不影响整体业务）.

负载均衡的算法

round robin 轮询 rr

负载均衡的默认算法，请求轮流分配给后端服务器。

轮询算法适合用于后端处理器能力相近的情况，默认的算法，可以不加。

默认

加权轮询-weight round robin

轮询的升级版，给每个后端服务器赋予不同的权重。

处理能力更强的服务器设置更高的权重，处理能力低的设置低权重。

高峰时间可以通过这个方法进行流量的优化，适用于服务器处理能力差异比较大的情况。

weight=number

ip_Hash

当我们访问后端服务器，根据客户端的IP地址，使用hash算法计算出IP地址的hash值，然后再根据请求发送到相应的后端服务器。

如果客户端访问的ip地址相同，通过hash算法，再一次的请求会分配到上一次访问的服务器，保证会话的稳定。

负载均衡的会话保持——>ip_Hash

会话保持到期之后，会话中断，重新请求会重新计算hash值。

ip_hash；

最小连接数

配合加权轮询一起使用，最小连接数的算法可以将请求发送到当前连接比较少的后端服务器。

这种算法适用后端服务器处理任务耗时不同的情况，可以有效的避免所有的请求集中在处理能力更强的后端服务器上。

least_conn；

weight=number

URL_Hash

根据请求当中url地址来计算hash值，如果客户端请求的url地址相同，客户端的请求会被分配到同一个服务器。

后台服务器的数量发生变化，会影响结果。（这个讨论无意义）

hash_$request_uri  consistest；

负载均衡的特点

1、根据算法把请求分配到不同的服务器

2、客户端访问的是代理地址，响应也是代理服务器响应。

3、客户端并不了解后端服务器的情况

4、可以提高安全性，后端服务器是隐藏的。

5、负载均衡是有缓存的，可以直接访问缓存，提高响应的速度。

负载均衡的架构

我们做个实验，三台主机，具体配置如下：

zw4：192.168.254.14（代理服务器）

zw5：192.168.254.15（后端）

zw6：192.168.254.16（后端）

客户端：浏览器

配置流量分发，主要是依靠服务器完成的，主要配置在代理服务器完成配置算法。

七层代理

upstream：模块仅支持http协议，用来处理http的请求和响应。

upstream只能写在http模块当中，不能在server也不能在全局。

基于IP的七层

轮询

配置完之后，我们访问主机（192.168.254.14）的nginx，会发现轮流访问的是设定的2台服务器的nginx，并且状态码为200，表示没有缓存。

加权轮询

这时候权重高的服务器被访问的次数多一点，状态码依然为200，没有缓存。

ip_hash

这时候第一次会根据hash算法匹配到一台服务器，之后再访问都是他了，并且状态码为304，表示访问缓存，这是根据IP地址的hash缓存，也是会话保持。

最小连接数配合轮询

这时候和轮询没什么区别，这是因为不好演示最小连接数，状态码依然为200。

URL_hash

这时候第一次会根据算法匹配到一台服务器，之后再访问都是他了，并且状态码为304表示缓存。注意：这里的缓存是url缓存，url地址不变才导致的访问服务器不变，并不是真正的会话保持。

最后我们停掉192.168.254.15的nginx后，会发现负载均衡依然再正常运行，并且只能访问192.168.254.16的nginx，证明了高可用。

基于域名的七层

 基于域名的七层代理

首先配置代理服务器zw4的nginx主配置文件

注意：1、如果使用域名才做七层，需要把客户端访问的真实IP地址传递给服务端

           2、如果经过代理，所有经过的代理地址也要传递给服务端

接着三台主机都配置域名解析，记得也要修改另外两台后端（zw5和zw6）的nginx上的localhost。

这时候我们发现负载均衡已正常工作，当然也是默认的轮询算法。

四层代理

stream：模块不支持http协议，仅支持tcp和udp，处理数据包流量分发。

四层代理只能写在全局模块当中。

根据上面的实验我们依然在代理服务器zw4上配置nginx的主配置文件，注意server中的端口号不能和下面http模块中server的端口号一样，所有这里我们随便定了个81。

重启nginx后，我们发现负载均衡的算法依然是轮询。

注意：

四层算法默认是轮询，也支持加权轮询和最小连接数支持。

ip_hash和uri_hash，不能在四层算法中使用，因为四层不能处理响应。