缓存角度的Apache负载均衡-lvs负载均衡和nginx负载均衡

Apache负载均很设置很多情况下都是根据tomacat来完成的，现在这片文章介绍的是关于反向代理实现apache负载均衡的配置过程，首先我们来参考一下前人的操作过程，根据那个方案来修改我们的实际操作。

下基于反向代理实现Apache负载均衡

初步设想:

考虑到对不同的 App Server 而言, 实现 Session 复制的配置各不相同(通常是需要配置集群), 因此从通用的角度, 觉得使用 session sticky 方式实现的负载均衡比较方便(没有看到有资料说 lighttpd 能够实现 session sticky, 所以决定使用 Apache 试试)

环境准备:

1､下载安装 Apache(不多废话了)

2､准备两个运行同样程序的 Web 服务器,这里使用的是 Tomcat 5.5, 并使用一个 jsp 文件作为测试文件

3､下载安装 JMeter ( jakarta-jmeter-2.2), 用于压力测试, 验证apache负载均衡的效果

测试jsp文件说明:

1､显示当前运行的服务器的 IP 地址及端口号, 这样从返回的页面就能够知道是运行在哪一个 Web 服务器上的了

2､统计每个客户端(不同的 session)向同一台服务器发出请求的次数, 通过这个计数可以验证是否实现了 session sticky

3､通过 clear 请求参数(即 .../test.jsp?clear=1)清除请求次数的计数结果, 以便进行下一次测试

4､模拟 JSESSIONID +jvmRoute 的机制, 自行实现了一个 STICK_PORT_TOKEN 的 Cookie, 直接使用不同服务器的 HTTP 端口号作为 route#p#

Apache负载均衡配置:

简单的反向代理

ProxyRequests Off  
<Proxy *> 
Order deny,allow  
Allow from all  
</Proxy> 
ProxyPass /1 http://localhost:8080/test  
#ProxyPassReverse /1 http://localhost:8080/test  
ProxyPass /2 http://localhost:18080/test  
#ProxyPassReverse /2 http://localhost:18080/test  
# 2)非 stickysession 的 balance  
ProxyPass /3 balancer://non-sticky-cluster nofailover=On 
<Proxy balancer://non-sticky-cluster> 
BalancerMember http://localhost:8080/test  
BalancerMember http://localhost:18080/test smax=10 
</Proxy> 
# 3)stickysession 的 balance  
ProxyPass /4 balancer://sticky-cluster stickysession=STICK_PORT_TOKEN nofailover=On 
<Proxy balancer://sticky-cluster> 
BalancerMember http://localhost:8080/test route=8080 
BalancerMember http://localhost:18080/test route=18080 loadfactor=2 
</Proxy>

这个配置分为3个部分, 包括了 1)简单的反向代理, 2)非 session sticky 的 load balance, 以及 3)session sticky 的 load balance 三种方式的配置(这里假设两个 Tomcat 服务器的 HTTP 服务被配置在 8080 和 18080 端口), 其中第 2) 和 3) 的配置中 "nofailover=On" 适合于没有 session 复制的情况下, 这种情况下, 如果其中一台 HTTP 服务器出错, 那么原来分配在这个出错机器上的浏览器客户端不会被自动转移到另外的服务器上, 必须重新启动浏览器才能将请求分配到另外一台服务器上去.#p#

使用 JMeter 测试结果:

使用 JMeter 对 "3)session sticky 的 load balance" 的效果进行测试, 通过压力测试的方式, 检查两台 Tomcat 服务器被分配到的请求数量(注意如果重复测试, 在下一次测试开始之前请对每个 Tomcat 服务器执行 .../test.jsp?clear=1 的请求, 清除上一次的计数结果).

从测试结果可见: 50个线程中有21个被分配在 8080 端口的服务器上, 29个则被分配到 18080 端口的服务器; 另外, 所有的 session 请求次数都是 20 次, 说明 session sticky 达到了预期的效果.

补充一下对 PHP 的 session sticky 配置问题:

对于使用 PHP 的朋友可能会在这里遇到一些问题,也许是因为 Apache 文档的误导,大家可能会照着上面的例子把 JSESSIONID 换为 PHPSESSID,但是这样是不行的!如果你有时间看看代码 modules/proxy/mod_proxy_balancer.c lines 195 to 210 也许你会发现一些问题,Apache 实际上在找一个类似于“balancer.www1"的 SESSIONID,我们可以配置 TOMCAT 来实现这种形式的 SESSIONID 但是 PHP 却没有这个功能｡但是,幸好我们能通过 Apache 的 Rewrite 功能来做这个事情｡

首先,假设我们后台有两台机器 www1.james.com 和 www2.james.com 我们先为他们配置 VirtualHost :

RewriteEngine on  
RewriteRule .* - [CO=BALANCEID:balancer.www{1或者2}:.james.com]

然后,我们在前台做apache负载均衡的机器上(假设为www.james.com)配置如下:

ProxyPass /bt balancer://sticky-cluster lbmethod=byrequests stickysession=BALANCEID nofailover=On 
ProxyPassReverse /bt balancer://sticky-cluster  
<Proxy balancer://sticky-cluster> 
BalancerMember http://www2.james.com/6d/session_test.php route=www2 
BalancerMember http://www1.james.com/session_test.php route=www1 
</Proxy>

重启 Apache 大功告成,我们访问 http://mail.james.com/bt 发现 .james.com 的 COOKIE 中除了 PHPSESSID 还出现了 BALANCEID,到这里我们已经成功了一半;然后,我们可以到apache 的 site_error log 中看到以下信息(设置 LogLevel debug):#p#

第一次登录:

BALANCER: Found value (null) for stickysession BALANCEID  
Entering byrequests for BALANCER (balancer://sticky-cluster)

第二次登录:

Found value balancer.www2 for stickysession BALANCEID  
Found route www2

之后,该用户的 session 就不会跳到 www1 上去了,直到 cookie 或 session 过期｡这样,我们就达到了“stick session"的目的了,真是形象啊,哈哈:)

以下是一些关于缓存的配置步骤摘要:

创建/var/www/proxy,设置apache服务所用户可写，mod_proxy配置样例:反相代理缓存+缓存架设前台的www.example.com反向代理后台的www.backend.com的8080端口服务｡修改:httpd.conf

<VirtualHost *> 
ServerName www.example.com  
ServerAdmin admin@example.com  
# reverse proxy setting  
ProxyPass / http://www.backend.com:8080/  
ProxyPassReverse / http://www.backend.com:8080/  
# cache dir root  
CacheRoot "/var/www/proxy"  
# max cache storage  
CacheSize 50000000  
# hour: every 4 hour  
CacheGcInterval 4  
# max page expire time: hour  
CacheMaxExpire 240  
# Expire time = (now - last_modified) * CacheLastModifiedFactor  
CacheLastModifiedFactor 0.1  
# defalt expire tag: hour  
CacheDefaultExpire 1  
# force complete after precent of content retrived: 60-90%  
CacheForceCompletion 80  
CustomLog /usr/local/apache/logs/dev_access_log combined  
</VirtualHost>