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

本文最后更新于：March 18, 2020 pm

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赋值为配置文件中的weight，current_weight赋值为0，effective_weight赋值为weight，total_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的情况。