On this page
Apache 模块 mod_lbmethod_byrequests
Description: | mod_proxy_balancer的请求计数负载均衡器调度程序算法 |
---|---|
Status: | Extension |
Module Identifier: | lbmethod_byrequests_module |
Source File: | mod_lbmethod_byrequests.c |
Compatibility: | 从 2.3 中的mod_proxy_balancer拆分 |
Summary
该模块不提供其自身的任何配置指令。它需要mod_proxy_balancer的服务,并提供byrequests
负载均衡方法。
请求计数算法
通过lbmethod=byrequests
启用后,此调度程序的思想是,我们在各个工作程序之间分配请求,以确保每个工作程序都获得了请求数量的已配置份额。其工作方式如下:
lbfactor 是我们期望该 Worker 工作多少或该 Worker 的工作配额。这是一个标准化的值,表示他们在工作量中的“份额”。
lbstatus 是该 Worker 必须完成其工作配额的紧急程度。
工作服务器是负载平衡器的成员,通常是服务于受支持协议之一的远程主机。
我们将每个 Worker 的工作配额分配给该 Worker,然后查看其中哪个 Worker 最需要紧急工作(最大 lbstatus)。然后选择该 Worker 进行工作,其 lbstatus 减去我们分配给所有 Worker 的总工作配额。因此,所有 lbstatus 的总和不会改变(*),我们将根据需要分配请求。
如果某些 Worker 被禁用,其他 Worker 仍将被正确安排。
for each worker in workers
worker lbstatus += worker lbfactor
total factor += worker lbfactor
if worker lbstatus > candidate lbstatus
candidate = worker
candidate lbstatus -= total factor
如果平衡器配置如下:
worker | a | b | c | d |
---|---|---|---|---|
lbfactor | 25 | 25 | 25 | 25 |
lbstatus | 0 | 0 | 0 | 0 |
并且 b 被禁用,产生以下时间表:
worker | a | b | c | d |
---|---|---|---|---|
lbstatus | -50 | 0 | 25 | 25 |
lbstatus | -25 | 0 | -25 | 50 |
lbstatus | 0 | 0 | 0 | 0 |
(repeat) |
就是这样的时间表:a c d c c d c d ...请注意:
worker | a | b | c | d |
---|---|---|---|---|
lbfactor | 25 | 25 | 25 | 25 |
具有与以下行为完全相同的行为:
worker | a | b | c | d |
---|---|---|---|---|
lbfactor | 1 | 1 | 1 | 1 |
这是因为 lbfactor 的所有值都相对于其他值进行了归一化。对于:
worker | a | b | c |
---|---|---|---|
lbfactor | 1 | 4 | 1 |
Worker b 的平均请求量是 a 和 c 的 4 倍。
以下非对称配置可以像预期的那样工作:
worker | a | b |
---|---|---|
lbfactor | 70 | 30 |
lbstatus | -30 | 30 |
lbstatus | 40 | -40 |
lbstatus | 10 | -10 |
lbstatus | -20 | 20 |
lbstatus | -50 | 50 |
lbstatus | 20 | -20 |
lbstatus | -10 | 10 |
lbstatus | -40 | 40 |
lbstatus | 30 | -30 |
lbstatus | 0 | 0 |
(repeat) |
也就是说,在 10 个计划之后,重复计划,并选择 3a,其中插入 7b。