负载均衡:将四层或者七层的请求分配到多台后端的服务器上。
从而分担整个业务的负载。提高系统的稳定性,也可以提高高可用(备灾,其中一台后端服务器如果发生故障不影响整体业务).
负载均衡的算法
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。
注意:
四层算法默认是轮询,也支持加权轮询和最小连接数支持。
ip_hash和uri_hash,不能在四层算法中使用,因为四层不能处理响应。