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。