nginx的负载均衡问题

最新推荐文章于 2023-03-25 13:00:03 发布

福海鑫森

最新推荐文章于 2023-03-25 13:00:03 发布

阅读量347

点赞数

分类专栏： Linux 文章标签： nginx 负载均衡运维

原文链接：https://blog.csdn.net/xxssyyyyssxx/article/details/119997466

版权

Linux 专栏收录该内容

101 篇文章 4 订阅

订阅专栏

nginx作为非常流行的反向代理软件，提供了几种负载均衡算法。
参考链接 https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/
http://nginx.org/en/docs/http/ngx_http_upstream_module.html#hash

一、负载均衡算法

round robin（默认）
weight
IP_hash
url_hash（第三方）
fair（第三方）
least_conn最小连接数
1.round robin（默认）
轮询方式，依次将请求分配到各个后台服务器中，默认的负载均衡方式。适用于后台机器性能一致的情况。挂掉的机器可以自动从服务列表中剔除。
2.weight
根据权重来分发请求到不同的机器中，指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。

upstream bakend {    
    server 192.168.0.14:8080 weight=10;    
    server 192.168.0.15:8080 weight=10;    
}

3. IP_hash
根据请求者ip的hash值将请求发送到后台服务器中，可以保证来自同一ip的请求被打到固定的机器上，可以解决session问题。ip_hash是使用ip地址的前三段进行hash运算，根据结果的不同，重定向到不同的服务器上。如果是内网的ip，算出的hashcode都是一样的，所以没有负载分担的效果。
例如：

upstream bakend {    
    ip_hash;    
    server 192.168.0.14:8080;
    server 192.168.0.15:8080;
    server 192.168.0.16:8080;
}

ip_hash虽好，但是有个问题是容易造成负载不均的情况，因为对源ip进行hash结果是不确定的。并且还有个很重要的tip：ip_hash使用的只有ip的前三段，比如192.168.0.14就只有192.168.0参与hash计算。所以使用此方法来解决session的问题不是特别完美。最好是利用redis这类共享存储来解决。
ip_hash当需要去掉某一台的时候，不要直接去除，否则可能造成大量的session失效，因为hash结果不对了。可以使用down的方式解决。当然在业务量小的时候修改也是完全可以的。

upstream bakend {    
    ip_hash;    
    server 192.168.0.14:8080 down;
    server 192.168.0.15:8080;
    server 192.168.0.16:8080;
}

ip_hash新增一台机器的时候，也会造成大量的session失效，所以最好在业务量很小的时候进行。
ip_hash是使用的普通的hash算法实现的，在新增机器或者减少机器的时候容易造成大量的session失效，于是可以使用第三方的一致性hash模块解决。参考链接http://www.fblinux.com/?p=1432
https://github.com/replay/ngx_http_consistent_hash
consistent_hash $remote_addr 可以根据客户端ip映射
consistent_hash $request_uri 根据客户端请求的url映射
consistent_hash $根据客户端携带的参数进行映射

4.url_hash（第三方）
根据请求的url的hash值将请求分到不同的机器中，当后台服务器为根据url缓存的时候效率高。
在upstream中加入hash语句，server语句中不能写入weight等其他的参数，hash_method是使用的hash算法。Nginx本身不支持url_hash，如果需要这种调度算法，则必须安装Nginx的hash软件包。

upstream backend {
server 192.168.0.14:8080;
server 192.168.0.14:8080;
hash $request_uri;
hash_method crc32;
}
hash $remote_addr consistent;
hash $request_uri;
hash $request_uri consistent;

5. fair（第三方）
根据后台响应时间来分发请求，响应时间短的分发的请求多。比 weight、ip_hash更加智能的负载均衡算法，fair算法可以根据页面大小和加载时间长短智能地进行负载均衡，也就是根据后端服务器的响应时间来分配请求，响应时间短的优先分配。Nginx本身不支持fair，如果需要这种调度算法，则必须安装upstream_fair模块。

upstream backend {   
    fair;   
    server 192.168.0.15:8080;
    server 192.168.0.16:8080;   
}

6. 最小连接数
根据后端连接数的多少决定分发给哪一台

upstream backend {   
    least_conn;   
    server 192.168.0.15:8080;
    server 192.168.0.16:8080;   
}

二、upstream中的调度状态
在Nginx upstream模块中，可以设定每台后端服务器在负载均衡调度中的状态，常用的状态有：

down，表示当前的server暂时不参与负载均衡
backup，预留的备份机器。当其他所有的非backup机器出现故障或者忙的时候，才会请求backup机器，因此这台机器的访问压力最低
max_fails，允许请求失败的次数，默认1，当超过最大次数时，返回proxy_next_upstream模块定义的错误。
fail_timeout，请求失败超时时间，默认10，在经历了max_fails次失败后，暂停服务的时间。max_fails和fail_timeout可以一起使用
Nignx负载均衡功能是通过upstream模块实现的，是基于内容和应用的7层交换负载均衡。Nginx负载均衡默认对后端服务器有健康检测能力，但是检测能力较弱，仅限于端口检测，在后端服务器比较少的情况下（10台及以下）负载均衡能力表现突出。与LVS负载均衡相比，LVS是基于四层的IP负载均衡技术，具有高性能、高可用、吞吐量大等优点，LVS在集群中表现更佳。

Nginx最大连接数问题
nginx 有一个 master，有四个 woker，每个 woker 支持最大的连接数 1024，支持的最大并发数是多少？

普通的静态访问最大并发数是： worker_connections * worker_processes /2，
而如果是 HTTP 作为反向代理来说，最大并发数量应该是 worker_connections *worker_processes/4。
————————————————
版权声明：本文为CSDN博主「恒奇恒毅」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/xxssyyyyssxx/article/details/119997466