Apache服务器配置反向代理实现负载均衡和双机热备

考虑到对不同的 App Server 而言, 实现 Session 复制的配置各不相同(通常是需要配置集群), 因此从通用的角度, 觉得使用 session sticky 方式实现的负载均衡比较方便（没有看到有资料说 lighttpd 能够实现 session sticky, 所以决定使用 Apache 试试）
环境准备：
1、下载安装 Apache（不多废话了）
2、准备两个运行同样程序的 Web 服务器，这里使用的是 Tomcat 5.5, 并使用一个 jsp 文件作为测试文件
3、下载安装 JMeter ( jakarta-jmeter-2.2), 用于压力测试, 验证负载均衡的效果
测试 jsp 文件说明：
1、显示当前运行的服务器的 IP 地址及端口号, 这样从返回的页面就能够知道是运行在哪一个 Web 服务器上的了
2、统计每个客户端(不同的 session)向同一台服务器发出请求的次数, 通过这个计数可以验证是否实现了 session sticky
3、通过 clear 请求参数(即 .../test.jsp?clear=1)清除请求次数的计数结果, 以便进行下一次测试
4、模拟 JSESSIONID +jvmRoute 的机制, 自行实现了一个 STICK_PORT_TOKEN 的 COOKIE, 直接使用不同服务器的 HTTP 端口号作为 route

Apache 的配置：
#######################################################
# Reverse Proxy and Load Balance ######################
#######################################################
# 1)简单的反向代理
ProxyRequests Off

Order deny,allow
Allow from all

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

BalancerMember http://localhost:8080/test
BalancerMember http://localhost:18080/test smax=10


# 3)stickysession 的 balance
ProxyPass /4 balancer://sticky-cluster stickysession=STICK_PORT_TOKEN nofailover=On

BalancerMember http://localhost:8080/test route=8080
BalancerMember http://localhost:18080/test route=18080 loadfactor=2


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

使用 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]
然后，我们在前台做负载均衡的机器上（假设为www.james.com）配置如下：
ProxyPass /bt balancer://sticky-cluster lbmethod=byrequests stickysession=BALANCEID nofailover=On
ProxyPassReverse /bt balancer://sticky-cluster

BalancerMember http://www2.james.com/6d/session_test.php route=www2
BalancerMember http://www1.james.com/session_test.php route=www1


重启 Apache 大功告成，我们访问 http://mail.james.com/bt 发现 .james.com 的 COOKIE 中除了 PHPSESSID 还出现了 BALANCEID，到这里我们已经成功了一半；然后，我们可以到 apache 的 site_error log 中看到以下信息（设置 LogLevel debug）：
第一次登录：
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

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


当然，现在主流的负载均衡技术绝不仅仅只是以上这些，文章最后，列举一些做备用知识：
1、DNS负载均衡（一种简单而有效的方法，但是存在不少问题，首先域名服务器无法知道服务结点是否有效；其次，由于DNS的数据刷新 时间TTL（Time to LIVE）标志，一旦超过这个TTL，其他DNS服务器就需要和这个服务器交互，以重新获得地址数据，因此为了使地址能随机分配，就应使TTL尽量短，然 而将TTL设置得过短，将使DNS流量大增，而造成额外的网络问题；最后，它不能区分服务器的差异，也不能反映服务器的当前运行状态。）
2、网络接入协议交换（大型的网络一般都是由大量专用技术设备组成的，如包括防火墙、路由器、第3、4层交换机、负载均衡设备、缓冲服 务器和Web服务器等。由于第四层交换基于硬件芯片，因此其性能非常优秀，尤其是对于网络传输速度和交换速度远远超过普通的数据包转发。然而，正因为它是 使用硬件实现的，因此也不够灵活，仅仅能够处理几种最标准的应用协议的负载均衡，如HTTP 。当前负载均衡主要用于解决服务器的处理能力不足的问题，因此并不能充分发挥交换机带来的高网络带宽的优点。）
总之，负载均衡是一种策略，它能让多台服务器或多条链路共同承担一些繁重的计算或I/O任务，从而以较低成本消除网络瓶颈，提高网络的灵活性和可靠性。