Apache Proxy lbmethod
基本上就是翻译文章,加上了一点自己的理解,先记录下来,以后理解深刻了在修改。
1.1 Request Counting Algorithm 请求计数算法
是一种基于轮循的请求计数算法,在每个worker 之间分发请求,确保每个worker 能够得到的请求数量 和配置的共享的请求数量一致。
ProxySet lbmethod=byrequests
lbfactor :一个worker 工作的频率
lbstatus :由worker 完成请求的紧急程度,数字越大越优先。所有的lbstatus的总和是不变的。
伪代码如下:每次请求都会执行代码
for eachworker in workers
worker lbstatus += worker lbfactor
total factor += worker lbfactor
if worker lbstatus > candidate lbstatus
candidate = worker
candidatelbstatus -= total factor
例一:
worker
| a
| b
| c
| d
| lbfactor
| 25
| 25
| 25
| 25
| lbstatus
| 25
| 25
| 25
| 25
| lbstatus
| -75
| 25
| 25
| 25
| lbstatus
| -50
| -50
| 50
| 50
| lbstatus
| -25
| -25
| 75-100=-25
| 75
| lbstatus
| 0
| 0
| 0
| 100-100=0
|
|
|
|
| 重复
|
选择顺序为a,b,c,d 然后又是a,b,c,d
例二:如果b down 掉了,那个lbstatus 的总和就为75,那么调度器的算法就如下所示:
worker
| a
| b
| c
| d
| lbfactor
| 25
| 0
| 25
| 25
| lbstatus
| -50
| 0
| 25
| 25
| lbstatus
| -25
| 0
| -25
| 50
| lbstatus
| 0
| 0
| 0
| 0
| (repeat)
|
调度策略就为a,c,d,a,c,d
1.2 Weighted Traffic Counting Algorithm 加权流量技术算法
lbmethod=bytraffic, 与 Request Counting方法相似其中主要变化如下:
lbfactor :是我们希望worker 处理的字节数,是从worker 能够看到的流量方面考虑。
例如:
worker
| a
| b
| c
| lbfactor
| 1
| 2
| 1
|
这意味着我们系统b相对于与a和c来说能够处理2倍的字节数。这并不意味着b能够处理2倍的请求,而是处理2倍的I/O。因此,请求和响应的数据 应用在了 加权和选择算法中。
1.3 Pending Request Counting Algorithm 等候的请求计数算法
lbmethod=bybusyness,
调度器记录了每个worker 当前被赋予了多少请求,新的请求被自动分发给那些活跃请求数最少的worker。对那些收到请求进行排队的workers 这个算法非常有用,为了让队列的长度保持稳定,一个请求总是给 那些可能响应最快的worker.
在多个 最不忙的workers中,由 Request Counting方法采用的统计经常会打破这个关系。慢慢的,请求的分发将演变成 byrequests 这个特征了。
这个算法在Apache HTTP Server2.2.10 版本之后由效果。 |