mod_lbmethod_byrequests
描述: | 请求计数mod_proxy_balancer的负载均衡器调度算法 |
状态: | 延期 |
模块标识符: | lbmethod_byrequests_module |
源文件: | mod_lbmethod_byrequests.c |
兼容性: | 在 2.3 中从mod_proxy_balancer分离 |
摘要
该模块不提供自己的任何 configuration 指令。它需要mod_proxy_balancer的服务,并提供byrequests
负载均衡方法。
请求计数算法
通过lbmethod=byrequests
启用,此调度程序后面的 idea 是我们在各种 workers 之间分发请求,以确保每个请求获得其配置的请求数。它的工作原理如下:
lbfactor 是我们期望这个 worker 工作多少,或 workers 的工作配额。这是一个标准化的 value,表示他们要完成的工作量的“份额”。
lbstatus 是这个 worker 必须努力完成其工作量的工作。
worker 是负载均衡器的成员,通常是 remote host,为所支持的协议之一提供服务。
我们将 worker 的工作配额分配给 worker,然后查看哪些工作需要最紧迫(最大的 lbstatus)。然后选择此 worker 进行工作,其 lbstatus 减少了我们分配给所有 workers 的总工作量。因此,所有 lbstatus 的总和不会改变(*),我们会根据需要分配请求。
如果某些 workers 被禁用,其他人仍将被正确安排。
for each worker in workers worker lbstatus += worker lbfactor total factor += worker lbfactor if worker lbstatus > candidate lbstatus candidate = worker candidate lbstatus -= total factor
如果平衡器配置如下:
工人 | 一个 | b | C | d |
lbfactor | 25 | 25 | 25 | 25 |
lbstatus | 0 | 0 | 0 | 0 |
并且 b 被禁用,产生以下时间表:
工人 | 一个 | 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 ...请注意:
工人 | 一个 | b | C | d |
lbfactor | 25 | 25 | 25 | 25 |
具有与以下完全相同的行为:
工人 | 一个 | b | C | d |
lbfactor | 1 | 1 | 1 | 1 |
这是因为 lbfactor 的所有值都相对于其他值标准化。对于:
工人 | 一个 | b | C |
lbfactor | 1 | 4 | 1 |
worker b 平均会得到 a 和 c 将要求的 4 倍。
以下非对称 configuration 按预期工作:
工人 | 一个 | 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 个时间表之后,时间表重复,并且选择 7a,其中散布有 3 个 b。