Nginx篇02——upstream模块中的加权轮询负载均衡

nginx的upstream模块中的加权轮询负载均衡的算法原理。

我们先来看一个简单的负载均衡:

1
2
3
4
upstream backend {    
server 10.0.0.1:80; #服务器a
server 10.0.0.2:80; #服务器b
}

这是一个简单的负载均衡,将接受到的访问按照默认的均分原则分配给后台的两台服务器,这时候两台server的访问量应该是1:1。如果我们在后面加上权重值,例如

1
2
3
4
upstream backend {    
server 10.0.0.1:80 weight=1; #服务器a
server 10.0.0.2:80 weight=2; #服务器b
}

这时候如果进行访问,我们得到的结果就应该是b a b,如果再进行修改权重

1
2
3
4
upstream backend {    
server 10.0.0.1:80 weight=5; #服务器a
server 10.0.0.2:80 weight=10; #服务器b
}

虽然两个权重化简之后都是1:2,但是这时候访问策略就有两种选择

  • 第一种是先连续访问server a5次再连续访问server b10次

  • 第二种是a b两台服务器轮流访问,但是总的访问次数比例符合5:10也就是1:2的比例。

显然第二种访问策略要更加优秀,可以避免一台服务器被连续访问多次而另一台服务器进入空闲状态。在nginx中的upstream模块实现这个操作使用了一个名为smooth weighted round-robin balancing的算法,直译过来就是平滑加权轮询负载均衡算法,大概意思就是实现上面说的第二种操作,下面我们用一个稍微复杂一点的配置来检验一下。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
upstream backend {    
server 127.0.0.1:8080 weight=3;
server 127.0.0.1:8081 weight=5;
server 127.0.0.1:8082 weight=7;
}

server {
listen 80;
server_name example.com www.example.com;

location / {
proxy_pass http://backend;
}
}

这里我们使用nginx监听在本机8080~8081三个端口,然后这三个端口作为本机的80端口的负载均衡后端,接着我们把权重设为比较复杂的3:5:7,然后我们进行实际测试。

得到的结果为,c b a c b c a c b c b c a b c,这里刚好15次也就是符合权重上面的加起来的总和,从结果来看这里的访问顺序比较均衡,但是细看又比较难找出规律。

我们去Github上面找到nginx的源码,对应的我们这里使用的测试的版本是稳定版的1.17.9,我们在目录下的nginx-master\src\http\ngx_http_upstream_round_robin.c当中可以看到这部分的实现源码,主要集中在该文件的前面部分。接下来我们需要理解源码中的几个变量:

  • weight:配置文件中设置的权重值,是定值,在整个选择过程中是不会改变的,对应到这里就是3、5、7。
  • current_weight:后端服务器的当前权重值,初始值等于0,在每轮选择中,该值最大的服务器就会被选中
  • effective_weight:变化权重值,初始值等于weight,用于动态调整服务器被选择的概率,即当被选中的服务器出现了failure的时候,该服务器对应的effective_weight就会减小,具体操作我们下面再解释。
  • total_weight:总的权重值,即所有服务器的权重值相加,在这里为3+5+7=15。

接下来我们开始逐步解析算法执行过程:

  1. 首先进行各类值的初始化,weight赋值为配置文件中的weightcurrent_weight赋值为0,effective_weight赋值为weighttotal_weight为所有weight之和;
  2. 对于每个服务器的current_weight,加上该服务器对应的weight
  3. 选取current_weight值最大的服务器来接受这次访问,然后该服务器对应的current_weight需要减去total_weight(因此current_weight是可以出现负值的)
  4. 不断重复步骤2和步骤3,当重复的次数等于total_weight时,所有服务器的current_weight刚好为0,此时结束一轮负载均衡。

从上面的步骤分析我们可以看出,当被选中的服务器出现了failure的时候,该服务器对应的effective_weight就会减小,在下面的current_weight加上该服务器对应的weight操作中就不能变得足够大导致被选中,从而就可以避免过多的访问被分配到出现了failure的服务器。

接下来我们进行简单的演算看看是否符合实际的输出结果:

操作 current_weight 选中服务器
初始化 (0,0,0) -
步骤2 (3,5,7) -
步骤3 (3,5,-8) c
步骤2 (6,10,-1) -
步骤3 (6,-5,-1) b
步骤2 (9,0,6) -
步骤3 (-6,0,6) a
步骤2 (-3,5,13) -
步骤3 (-3,5,-2) c

下面的步骤就不继续演示了,当步骤2和步骤3重复了total_weight次,也就是相当于一轮之后,current_weight就会正好全部变回0,而前提是过程中没有出现服务器failure的情况。