porxy负载均衡的验证

在我们学习负载均衡的一些软件配置的时候，很多朋友或者网友都会参考网络上面的一些资料，但是由于很多文章是源于博文的一些内容，正确性本身就存在着一些差异。那么我们在浏览文章之后需要对这个程序最好进行一个实际的操作，看看其中有没有什么错误。现在我们就来分享一篇关于porxy的负载均衡模块的测试内容。

由于一些历史遗留问题，需要使用lighttpd的mod_porxy模块进行负载均衡，于是对mod_porxy 支持的3种负载均衡算法进行了简单测试。大致的过程如下:

1、mod_porxy 3种负载均衡的含义

a)fair(默认)

根据各节点负载均衡情况，进行动态调配。

b)hash

对url进行hash，将同样的请求转发到同一节点。

c)round-robin

各节点轮训轮发

2、测试环境

lighttpd节点：192.168.0.1

web节点A : 192.168.0.2

web节点B : 192.168.0.3

访问节点C： 192.168.0.4

配置文件内容：

$HTTP["url"] == ".shtml" {

proxy.balance = "fair"

# proxy.balance = "round-robin"

# proxy.balance = "hash"

proxy.server = (

"" => ( ( "host" => "192.168.0.2", "port" => 80 ) ,

( "host" => "192.168.0.3", "port" => 80 ) )

)

}

3、关于模块负载均衡的测试方法

a)测试fair、round-robin

使用siege在节点C发送1000个相同url到节点A，分别测试fair、round-robin

siege -c 100 -r 10 -u http://192.168.0.1/test.shtml

b)hash

通过线上访问日志生成1000个不同url写入文件test.txt，使用siege读取url测试hash

siege -c 100 -r 10 -f test.txt

4、porxy负载均衡测试结果

通过统计A、B节点访问日志发现，只有fair方式调度2个服务端口比较均衡。而hash、round-robin算法将访问全都转发到配置文件中靠前的 A节点，而靠后的B节点基本没有请求。

看来只有fair方式比较靠谱，hash、round-robin形同虚设没有什么意义。

5、关于fail-over

a)fair

具备端口监测功能，可以自动屏蔽问题节点。当lighttpd检测A节点挂掉，当前请求就会503错误返回，下一个请求才会转到B节点。A节点恢复后，lighttpd不会自动恢复对A节点的转发，需要重启lighttpd才能恢复。

b)round-robin

不具备端口监测，节点挂掉后也会不停转发请求。

mod_proxy做负载均衡确实存在不小的问题，如需要使用建议使用fair算法。