一，nginx的负载均衡集群的特点:
1,nginx集群和lvs的不同？
lvs集群:工作在第4层(传输层)
nginx集群:工作在第7层(应用层) lvs集群:性能更强
nginx集群:功能更强:可以针对域名/目录等进行配置 lvs:不支持重发请求
nginx集群:检测到错误后可以重发请求
2，调度算法有哪些？
rr (轮询)
wrr (就是rr的基础上加上权重weight)
ip_hash (根据ip分发)
url_pash (根据url分发)
least_conn (分发给连接数少的机器)
fair (按响应时间分发，是第三方的算法，如使用需要安装时添加相应的模块)
说明：刘宏缔的架构森林是一个专注架构的博客，地址：https://www.cnblogs.com/architectforest
对应的源码可以访问这里获取： https://github.com/liuhongdi/
说明：作者:刘宏缔 邮箱: 371125307@qq.com
二，我们作为例子的nginx负载均衡集群的结构:
loader: 172.18.1.1 loadbalancer,负责作为负载均衡的入口
web1: 172.18.1.2 后端的web机器之一
web2: 172.18.1.3 后端的web机器之二
三，loader上负载均衡集群的配置
1，编辑配置文件：用upstream定义一个集群
#upstream :定义一个上游服务器集群
#webcluster :集群的名称，用来区分
#server 172.18.1.2:80 指定集群的机器ip的端口
upstream webcluster{
server 172.18.1.2:80;
server 172.18.1.3:80;
}
2,在server配置访问中使用上面定义的webcluster集群
server {
listen 80;
server_name localhost;
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_buffering off;
proxy_connect_timeout 5;
proxy_read_timeout 5;
proxy_send_timeout 5;
proxy_pass http://webcluster;
}
}
3,配置中各个指令的说明：
proxy_pass
将代理转发给上方 upstream 中配置的集群中的两台服务器去处理
X-Real-IP
用来得到真实ip,否则在后端看到的都是loader的ip
proxy_set_header X-Real-IP $remote_addr;
proxy_buffering
默认值是on,这里我们把它关闭,off
它负责开启从后端被代理服务器的响应body缓冲，
我们需要从后端服务器按收实时的数据，所以关闭
proxy_connect_timeout
该指令设置与upstream server的连接超时时间，默认值60s，最高不能超过75秒
注意这个不是等待后端返回页面的时间(那个时长是由proxy_read_timeout变量来定义)。
如果upstream服务器正在运行中，但是没有响应
则这个指令不会起作用，因为与upstream服务器的连接已经建立
proxy_read_timeout
该指令设置与代理服务器的读超时时间。它决定了nginx会等待多长时间来获得请求的响应
如果两次读操作之间经过指定的时间还收不到upstream响应的数据，视为超时
默认值:60s
proxy_send_timeout
这个指定设置了发送请求给upstream服务器的超时时间
如果两次写操作之间经过指定的时间不能发送到upstream,视为超时
默认值:60s
四，nginx集群的轮循算法:
1,默认算法:轮询
轮询是upstream的默认分配方式，
每个请求按照时间顺序轮流分配到不同的后端服务器
2,使用ip_hash算法：
# ip_hash: 根据ip地址做hash,使同一个ip发出的请求能分发到相同的后端机器
upstream webcluster{
ip_hash;
server 172.18.1.2:80;
server 172.18.1.3:80;
}
如果同一个ip发出的请求能分发到相同的后端机器,
则一定程度上可以提高访问效率，因为可以避免多次建立http连接
注意：如果用户使用带有服务端缓存功能的浏览器（比如微信的内置浏览器），
则用户的ip地址会发生变化,
所以如果做session共享时不能寄希望于ip_hash
3，使用url_hash算法
说明: url hash把相同的请求地址转发到后端相同的机器
upstream webcluster{
hash $request_uri;
server 172.18.1.2:80;
server 172.18.1.3:80;
}
如果后端的web服务机器上有本地缓存，且缓存内容不同，可以使用这种方式
因为可以提高缓存命中率，缩短访问时间
比如：供下载用的文件缓存到web服务器
如果缓存内容相同,例如 redis缓存页面内容，则使用url_hash带来的益外不大
五，负载均衡的参数例子：
1，weight:
机器在集群中占的权重，默认值是1
weight越大，负载的权重就越大，
如果后端服务器的性能或带宽有差异时，可以用这个值来调整压力的分配
例子：
upstream webcluster{
server 172.18.1.2:80 weight=1;
server 172.18.1.3:80 weight=2;
}
说明:使用ip_hash和url_hash算法时weight不生效
2,max_fails /fail_timeout
例子：
upstream webcluster{
server 172.18.1.2:80 max_fails=3 fail_timeout=60s;
server 172.18.1.3:80 max_fails=3 fail_timeout=60s;
}
在fail_timeout参数定义的时间段内，如果失败的次数达到max_fails的值，Nginx就认为服务器不可用,标记此机器为fail,
当前的fail_timeout时长内不再尝试连接，
到下一个再去尝试请求，如果连接成功，则恢复之前的分发，
如果仍然不可用，则继续等到下一个周期再尝试
默认值:
fail_timeout为10s
max_fails为1次
建议值:
机器出故障一般没那么容易恢复，
建议设置为: 3/60
说明：
后端服务器连接失败时，会记录到error_log日志中:
例：
2020/05/12 05:44:32 [error] 483#0: *7 connect() failed (111: Connection refused) while connecting to upstream,
client: 172.18.0.1, server: localhost, request: "GET / HTTP/1.1", upstream: "http://172.18.1.3:80/", host: "192.168.3.59"
3，down
表示此服务器已被手动停用
例子：
upstream webcluster{
server 172.18.1.2:80 max_fails=3 fail_timeout=60s down;
server 172.18.1.3:80 max_fails=3 fail_timeout=60s;
}
4，backup
表示此服务器是备用服务器，
只有其它后端服务器都宕机或者很忙才会访问到
所以在集群中压力最小
例：
upstream webcluster{
server 172.18.1.2:80 max_fails=3 fail_timeout=60s;
server 172.18.1.3:80 max_fails=3 fail_timeout=60s backup;
}
六，查看nginx版本
[root@centos8 playbook]# /usr/local/soft/nginx-1.18.0/sbin/nginx -v
nginx version: nginx/1.18.0