负载均衡一般用轮询和加权轮询,hash负载均衡很少用到
1、轮询
upstream tomcats {
server 192.168.40.22:8088;
server 192.168.40.23:8088;
server 192.168.40.24:8088;
}
server {
listen 80;
server_name www.tomcats.com;
location / {
proxy_pass http://tomcats; #这里用到的tomcats就是upstream模块定义的名称
}
}
默认情况下,会使用轮询方式向后端服务器发起请求,即平均分配请求,每个正常运行的服务器获得的请求数量是一样的。
2、加权轮询
upstream tomcats {
server 192.168.40.22:8088 weight=1;
server 192.168.40.23:8088 weight=3;
server 192.168.40.24:8088 weight=5;
}
server {
listen 80;
server_name www.tomcats.com;
location / {
proxy_pass http://tomcats; #这里用到的tomcats就是upstream模块定义的名称
}
}
在轮询的配置基础上,添加参数weight,指定当前服务器的权重,weight的值越大,说明当前服务器被分配的请求数量就越多,反之,则被分配的请求数量就越少。
3、ip_hash
upstream tomcats {
ip_hash; # 在基础轮询配置上添加该语句,就能实现ip_hash功能
server 192.168.1.173:8080;
server 192.168.1.174:8080 down;
server 192.168.1.175:8080;
}
ip_hash
可以保证用户请求到上游服务中的固定的服务器,前提是用户ip没有发生更改。
使用ip_hash的注意点:如果后台某一台服务器需要临时移除,这时千万不能把这台后台服务器从配置中直接移除,只能标记down,因为直接删除后,nginx会从新计算用户IP到服务器的映射关系,这时候几乎所有的后台服务器所保存的会话都会失效,因为同一用户IP很大概率会被分配到另外的后台服务器。
下面是ip_hash的实现原理(可以不看):
nginx先计算客户端的ip地址的hash值,然后用得到的hash值对后台服务器节点数进行模运算,得到的值就是后台服务器的索引值。
nginx在计算ip的hash值的时候,只会用ip地址的前三位数值进行运算,所以在用内网测试的时候,所有请求都会被分配到同一台服务器节点上。
ip_hash的缺点就是不论服务器增加还是减少(比如宕机),都会导致nginx对所有请求重新进行hash(ip)运算(服务器数量发生变化),之前服务器保存的会话信息几乎都会失效,所以不推荐使用这种方式。
4、一致性hash算法(需要Nginx引入第三方模块)
一致性hash内容较多,这里引入其他人写的一篇文章 https://www.cnblogs.com/mcgrady/p/10268214.html
5、url_hash
根据每次请求的url地址,hash后访问到固定的服务器节点,道理与ip_hash一样。
upstream tomcats {
hash $request_uri; # 表示对客户端请求的URI进行hash运算
server 192.168.1.173:8080;
server 192.168.1.174:8080;
server 192.168.1.175:8080;
}
server {
listen 80;
server_name www.tomcats.com;
location / {
proxy_pass http://tomcats;
}
}
6、least_conn
nginx在接收到用户的请求时,会选择集群中连接数最少的那台服务器。
upstream tomcats {
least_conn;
server 192.168.1.173:8080;
server 192.168.1.174:8080;
server 192.168.1.175:8080;
}
server {
listen 80;
server_name www.tomcats.com;
location / {
proxy_pass http://tomcats;
}
}