nginx做为方向代理时,能够为后端服务器提供负载均衡的功能,其中加权轮询策略使是其默认的负载均衡策略。
(1) peer[n].weight:后端服务器初始权重。 (2) peer[n].current_weight:后端服务器当前权重,初始情况等于peer[n].weight。 (3) peers->number:后端服务器的个数 (4) peers->peer[0]:一个数组的第一个元素,这个数组的每个元素对应一个后端服务器。 (5) 一旦某个后端服务器n被选中后,会在其他处理函数中执行peer[n].current_weight–。 (6) 代码18行乘以1000是为了避免浮点处理,所以直接报被除数放大1000倍,也就是间接把精度提升到小数点后三位,注意这里是权值的比较,因此把两边权值都放大1000倍并不会影响最终的比较结果。 static ngx_uint_t ngx_http_upstream_get_peer(ngx_http_upstream_rr_peers_t *peers)
18~19行代码是选取后端服务器的关键,那么这个条件是如何确保选取后端服务器负载均衡呢? 假设有三台后端服务器A、B、C,它们的权值分别为5、3、1。那么执行过程如下: (1) 第一次请求由于peer[n].current_weight= peer[n].weight&&peer[i].current_weight= peer[i].weight,所以代码18行的条件始终不成立。13行的while循环到i=2时退出。接着执行到25代码行条件成立,n=i=2,所 以第一次选中服务器C,之后服务器C的current_weight–,当前权值变为0。 (2) 第二次请求到来时,A、B、C的权值为5、3、0。代码执行到14行时,i=1,n=0,此时由于A和B的current_weight和weight相 同,条件依然不成立,23行使n=i=1,然后i++变为2,但代码15行条件成立(C的current_weight为0),继续循环到13行代码不成 立。此时跳出13行的while循环,执行到18行返回n=1,即选择服务器B。 (3) 第三次请求到达时,A、B、C的权值为5、2、0。执行到代码14行时n=0,i=1,随后18行条件成立 (peer[n].current_weight=5,peer[i].current_weight=2,peer[n].weight=5,peer[i].weight=3), 所以19行返回n=0,即选中服务器A。 (4) …… (5) 随后请求处理类似,知道所有服务器current_weight都等于0。此时第8行的for循环跳出,执行第30行条件不成立,执行33行,再次将current_weight重置为初始值。 这样一个过程确保链接的处理按照服务器配置的权重来均衡。
可以看出nginx每次选出的服务器并不一定是当前权重(处理能力)最大的,如上分析第一次请求选取的并不是服务器A,而是C,但就总体效果而言如果请求数量足够多最终可以实现让客户的请求在整体上根据服务器的权值在各个服务器上按照对应比例分布。
应用这个负载均衡逻辑就可以实现对客户端的请求按照服务器的处理能力(权重)进行负载均衡了。 |