Apache HTTP Server 版本 2.4
描述 | 针对 mod_proxy_balancer 的请求计数负载均衡调度算法 |
---|---|
状态 | 扩展 |
模块标识符 | lbmethod_byrequests_module |
源文件 | mod_lbmethod_byrequests.c |
兼容性 | 从 2.3 版本开始从 mod_proxy_balancer 中分离 |
此模块本身不提供任何配置指令。它需要 mod_proxy_balancer
的服务,并提供 byrequests
负载均衡方法。
通过 lbmethod=byrequests
启用,此调度程序背后的理念是,我们将请求分配到各个工作进程,以确保每个工作进程都获得其配置的请求数量份额。其工作原理如下
lbfactor 是我们期望此工作进程完成的工作量,或工作进程的工作配额。这是一个标准化值,表示其完成工作量的“份额”。
lbstatus 是此工作进程为了完成其工作配额而需要工作的紧迫程度。
工作进程 是负载均衡器的一个成员,通常是提供支持协议之一的远程主机。
我们将每个工作进程的工作配额分配给该工作进程,然后查看哪个工作进程最需要工作(最大的 lbstatus)。然后选择此工作进程进行工作,并将分配给所有工作进程的总工作配额从其 lbstatus 中减去。因此,所有 lbstatus 的总和不会改变(*),我们按预期分配请求。
如果某些工作进程被禁用,其他工作进程仍将按正确顺序调度。
for each worker in workers
worker lbstatus += worker lbfactor
total factor += worker lbfactor
if worker lbstatus > candidate lbstatus
candidate = worker
candidate lbstatus -= total factor
如果负载均衡器配置如下
工作进程 | a | b | c | d |
---|---|---|---|---|
lbfactor | 25 | 25 | 25 | 25 |
lbstatus | 0 | 0 | 0 | 0 |
并且 b 被禁用,则会生成以下调度
工作进程 | a | b | c | d |
---|---|---|---|---|
lbstatus | -50 | 0 | 25 | 25 |
lbstatus | -25 | 0 | -25 | 50 |
lbstatus | 0 | 0 | 0 | 0 |
(重复) |
也就是说,它调度:a c d a c d a c d ... 请注意
工作进程 | a | b | c | d |
---|---|---|---|---|
lbfactor | 25 | 25 | 25 | 25 |
具有与以下完全相同的行为
工作进程 | a | b | c | d |
---|---|---|---|---|
lbfactor | 1 | 1 | 1 | 1 |
这是因为所有 lbfactor 值相对于其他值都是标准化的。对于
工作进程 | a | b | c |
---|---|---|---|
lbfactor | 1 | 4 | 1 |
工作进程 b 平均会获得 a 和 c 的 4 倍请求。
以下非对称配置按预期工作
工作进程 | 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 |
(重复) |
也就是说,在 10 次调度后,调度会重复,并且会选择 7 个 a,并插入 3 个 b。