步骤：

1. 安装Apache基本模块
2. 后台监控
3. 负载均衡简单测试
4. 配置Tomcat相关模块（AJP）
5. 保持Session唯一，粘性会话
6. Tomcat集群，Session复制

1.安装Apache相关模块 负载均衡需要的主要是代理模块！ 经过几次Apache配置尝试，在Ubuntu下配置Apache实在是太容易了。加载什么模块、取消什么模块两个命令搞定。 这里，我们需要让Apache提供代理服务，其中又包含基于http、ftp、ajp等等协议的代理功能，同时还需要负载均衡模块。我们可以通过命令逐个加载： 完成上述操作后，系统会提示重启Apache！ 先不着急重启，现学现卖，了解下Apache的目录结构。在Ubuntu下配置Apache主要是在 /etc/apache2目录下： 分述：

• apache2.conf核心配置文件，一般不需要修改！
• conf.d目录，里面包含了一些字符集设置，文档等设置！
• dav_svn.authz和dav_svn.passwd是前面做SVN时，相关权限、密码文件。
• envvars定义了运行时的用户身份——www-data。
• httpd.conf是Apache留给我们自己折腾的配置文件，默认为空。apache2.conf会加载这个文件。
• ports.conf端口默认配置。apache2.conf会加载这个文件。
• magic为mod_mime_magic模块服务。
• mods-enabled和mods-available mods-enabled会被apache2.conf加载，里面包含*.load和*.conf文件。*.load文件中是加载相应的模块（位于/usr/lib/apache2/modules/中），而*.conf中是对应的基本配置。但这些文件其实都是链接到mods-available中相应的文件上。当我们通过a2enmod操作时，实际上正是操作了这些软链接。
• sites-available和sites-enabled 与 mods-enabled和mods-available的关系类似，只是其中包含的是站点内容。

罗嗦了一堆，下面配置负载均衡部分。 执行修改： 上图红框中的内容是原始内容，白框中的内容是我新加的部分。 注意红框中的配置： 在默认配置中，Deny from all处于可用状态。当我们配置其他代理节点时，将导致杜绝访问！使用 Allow from localhost ip6-localhost 限制仅允许本机访问！ 再说，白框中的内容： 这里，我配置了一个负载均衡节点 balancer://zlex，其中包含了两个服务 http://localhost:8080/和 http://192.168.49.1:8080/，一个是虚拟机上的Tomcat、一个是真机上的Tomcat。这里使用的Http的转发方式，当然，使用AJP未尝不可，稍后详述！ 这里的节点次序会有一个先后关系，Apache会将请求按照FIFO的方式调度顺次分配到各个节点上！如果其中有一个节点挂掉，将跳过该节点顺次寻找可用节点。 再说代理和反向代理： 这里配置，如果要访问 /zlex路径时，将跳转到 balancer://zlex上，也就是享受负载均衡！ 2.后台监控 我们如何知道某个节点负载多少，响应时间多久，服务是否正常呢？Apache提供了负载均衡监控平台： 。但是，这个服务默认是不存在。 除了用于负载均衡配置、监控的 balancer-manager还有 和 我们需要添加info模块： 同时，为了能够使用 balancer-manager，我们需要配置： 把这段代码放到哪？由于它同属系统信息配置，我把它放到了 info.conf中，说白了就是照猫画虎： 注意，这段代码放到了 <IfModule mod_info.c>和 </IfModule>之间！ 现在，我们重启Apache： 来看看管理界面 ： 我们再来看看服务器基本信息 ： 上述两个服务需要加载info模块，而服务器状态（server-status）不需要 ： 3.负载均衡简单测试 疯狂访问 ，直到手酸眼烦！ 我这里故意使用不同了Tomcat界面，来验证自己的配置是否生效。更疯狂的是，我甚至把节点指向了百度、搜狐，来测试负载均衡的效果。如果你细致观察，Apache是将请求顺次分配到各个节点上的。 如果其中一个节点发生问题（例如，强行关闭一个Tomcat，或配置一个错误节点）Apache将会经过几次尝试后，绕过这个问题节点，寻找可以成功访问的节点。如果这个节点恢复正常使用，Apache将在该Tomcat恢复正常工作后大约1分钟内将该节点标识为可用！ 现在，再看看现在的后台（ ）啥样子： 如果我们控制一个节点的状态是否可用，该怎么做： 涉及到负载量，session同步等等，我们最后讨论！ 4.配置Tomcat相关模块（AJP） 基于Http协议分发并不复杂，但AJP效果更好！一次诡异事件中，内网访问正常，外网访问多次失败，最后通过AJP方式完美解决了！ 在Tomcat中配置AJP也很简单，修改 server.xml开启AJP模块： 开启AJP配置： 注意使用的端口port="8009"，字符集URIEncoding="UTF-8"，这是输入框、请求字符集乱码的入口！ 接下里就可以通过AJP方式进行节点分发了。修改 /etc/apache2/mods-available/proxy.conf ： 将 http改为 ajp，将 8080改为 8009： 重启Apache： 再看看管理界面 至此，我们完成了基本负载均衡的基本配置！ /etc/apache2/mods-available/proxy.conf还有一些属性: noFailOver是否打开失败转移， On| Off，默认为Off，添加在 ProxyPass后面，如： 如果这样配置，当提供给你服务的服务器发生异常，那么你将一直看着它返回给你503，直到系统恢复正常！ loadfactor表示后台服务器负载到由Apache发送请求的权值,默认值为1添加在 BalancerMember后面： 可以实现三种策略：

1. 轮询均衡策略的配置
2. 按权重分配均衡策略的配置
3. 权重请求响应负载均衡策略的配置

5.Session唯一，粘性会话 Apache已经可以轻松将内容处理的工作分配给各个Tomcat了！ 当然，这还不够，Session还是个问题！

WHY？ 我们来做一系列修改，来检测Session到底出现了什么问题！ 先来改造Tomcat，修改 server.xml： 修改 <Engine />节点，增加 jvmRoute属性： 另一个Tomcat设置改为 通过 jvmRoute，指定了Tomcat唯一标识！ 然后修改 /etc/apache2/mods-available/proxy.conf 如下： 这里需要通过修改 route属性，将Apache与Tomcat关联起来！ 注意，Tomcat中定义的jvmRoute需要与Apache定义的route相对应！ 我们来看一下 发生了什么变化： 我们注意到route字段有了新的标识，当然，我们也可以通过这个配置界面修改这些信息，但当前修改不会真的修改/etc/apache2/mods-available/proxy.conf文件，Apache重启后将丢失。 为了更细致的对比进过复杂均衡的结果，这里增加了zlex应用！主要是监控Session的变化！ 只看核心代码： 将其做成一个名为zlex的web应用，分别部署到两个Tomcat上！ 然后重启Apache： 不断刷新 ，看看真正的结果： 第1次： 第2次： 第3次： 第4次： 仔细观察，每次请求都按照负载均衡配置的节点次序依次请求到不同的Tomcat上。尤其是当我们通过 jvmRoute和 route做了绑定之后，信息更加准确。但是， 仔细观察，每次请求的SessionID都是不一样！对于纯Web应用，尤其是依靠SessionID区分唯一用户的应用，这将是一场噩梦——解决了服务器压力均衡问题，却带来了SessionID不唯一问题！这就需要SessionID绑定，或者说叫做“会话复制”。 如果这时候你在页面上提交表单，将键值对保持在session中，在页面刷新后，将无法获得该信息，因为Seesion丢失了！ 接着修改 /etc/apache2/mods-available/proxy.conf，让SeesionID保持唯一： 增加 stickySession属性： stickySession粘性会话，根据这一属性，浏览器将通过cookie绑定SeesionID。如果这个时候再次访问 ，你会发现，页面不会来回跳转了！ sticky是什么？ 提交一个Session设定看看 ： 观察后台日志： 再看看返回页面，这相当于一次页面刷新，如果正常粘性会话，我们将获得当前SessionID对应的一切信息： 这说明粘性会话生效了！ 我们得到了形如 的SessionID。这样，我们就能知道当前访问的是哪台服务器了！ 如果，换一个浏览器打开该页面，将会获得一个新的SessionID，并且，根据Apache中配置的负载均衡节点列表依次访问下一个节点！

如果这时候负载均衡节点列表中某一节点发生异常，那么Apache将按照惯例，跳转该节点，并在该节点恢复正常后约1分钟内重新将其纳入可用节点！ 修改刚才的jsp页面，看看Http头中都有些什么： sticky模式的根本在于浏览器支持cookie，如果浏览器不支持cookie，则需要修改server.xml文件中的<Context />节点，将cookie置为false，关闭cookie功能，让jsessionid显式传递！ 6.Tomcat集群，Session复制 经过两天反复研究，两只互不相认的Tomcat终于在网络上“资源共享”了——Session复制成功！ 关于 Tomcat集群以及Session复制，网上已经有很多很多，但是否真的能用？！为了确认这一问题，周末还跑到书店翻了翻《Apache Tomcat 高级编程》，参考 （有点小错误），经过两天苦战，克服种种小问题，终于拿下！ 整理概念： Session复制核心内容主要是：

1. Session内容序列化（serialize），会消耗系统性能。
2. Session内容通过广播同步给成员，会造成网络流量瓶颈，即便是内网瓶颈。

因此，Session复制的这两个潜在问题，致使复杂均衡节点最多不会超过4个。因为，当节点数大于4时，整个集群的吞吐量将不再上升！ 为了搭建Tomcat集群，我将两个Tomcat分别部署到两台虚拟机上，确保网段一致。（这一步很关键，我最初将 Tomcat1（192.168.49.132）部署在虚拟机上，将 Tomcat2（192.168.49.128）部署在本机上，结果，网络总有问题，耽误了很多时间。 ） 由于变换了IP，我需要修改Apache的 /etc/apache2/mods-available/proxy.conf文件： 修改负载均衡节点如下： 对于windows系统，不需要考虑网络问题，广播地址（这里用到 224.0.0.0和 240.0.0.0）默认开放，对于linux则需要通过命令开放地址。 Ubuntu上开放广播地址（eth0网卡）： 然后通过 -v参数查看当前开放的广播地址： 注意，重启后，该路由设置将丢失！ 在Ubuntu下，可以考虑修改 /etc/networks文件！ 如果有必要，Windows上开放广播地址（192.168.49.128本机地址）： 然后通过 print参数查看当前开放的广播地址： 然后，修改tomcat的server.xml文件： 在 <Engine /> 节点中加入如下内容： 这里需要注意 <Membership />和 Receiver： <Membership />节点的 address属性是广播地址； Receiver节点的 address属性是本地绑定地址。当然，默认为 auto。由于我在启动Tomcat时，Tomcat频频将地址指向 127.0.0.1，无奈只好使用固定IP。 此外，为了降低Session复制的成本，Tomcat通过 <Valve />节点，以过滤器的方式控制哪些请求可以忽略Session复制： 同时，在<Host>节点中加入如下内容： 在Tomcat的官方文档（Tomcat 6）中，对于<Deployer  />节点的部署位置是错误的，通过观察Tomcat启动日志，确认该节点应当不属于<Host />节点中！ 注意：Tomcat 6与Tomcat5在上述节点中使用的类包（包中名称由cluster变化为ha）有所不同，且结构有所调整。 先别急着重启，我们需要修改应用中的 web.xml文件，将 <distributable />节点部署到 <web-app />节点中，开启分布式服务： 注意：如果没有设置该节点，SessionID将不能保持同步，不同的服务器将各自建立独立的SessionID！ 监控Tomcat日志： 然后重启Tomcat1： 观察日志： 注意两处红框：

第一处，Cluster启动，并绑定192.168.49.132:4000上，进行TCP通讯，并等待其它成员（Member）。

第二处，在管理器中注册/zlex，绑定JvmRouteBinderValve。 至此，说明集群设置已经生效，但不能说明集群配置成功！ 接着我们启动Tomcat2，观察其日志： Cluster启动，并绑定192.168.49.128:4000上并发现成员[b]192.168.49.132！[/b] 再看Tomcat1的日志： Tomcat1发现其成员Tomcat2！这说明TCP通讯已建立，Tomcat成员可以进行Session同步！ 同时，Tomcat成员直接会每隔一个时间段相互侦测/验证其他成员是否正常： 现在，开始访问 ，并不断刷新当前页面： 除了两处标识主机来源的tomcatX不同外，session是完全一致的！ 提交一次修改，并不断刷新当前页： 如果仔细观察，当前SessionID在不断交替变化，这说明负载均衡在起作用！ 我们再来看看2个Tomcat后台日志都做了什么！ Tomcat1： Tomcat2： 两只猫都打印了相同的内容（ a=1）不同的细节在于，sessionID带有服务器标识！ 如果我们强行关闭Tomcat2： 首先，Tomcat1会很快侦测到Tomcat2离线，因为这是TCP通讯，成员之间很容易检测到其他成员是否离线！Tomcat1后台日志如下： 其次，Apache会侦测到Tomcat2发生异常，将其余请求转交给其他节点，即交由Tomcat1处理！ 继续刷新 当前页面，耐心等待几秒。你会发现，即便再次刷新页面，sessionID仍旧绑定在标识tomcat1服务器上。 然后，我们恢复Tomcat2服务，Tomcat1会马上侦测到Tomcat2已经恢复正常： 最后，我们再次刷新当前页，Apache已经将请求分发给Tomcat2了，从后台日志可以看到session信息会很快被同步了！ 如果带有tomcatX标识的sessionID有很多不便之处，可以关闭粘性会话。简单的讲，就是取消Tomcat中[b]server.xml中 <Engine/ >节点的 jvmRoute属性！[/b]然后，重启tomcat、apache！ 页面提交一个 b=3！ 左边为Tomcat1，右边为Tomcat2！SessionID一致！ 除了上述几种方案外，还有 模式。一种第三方集群组件，2009年收购了缓存组件EhCache，可以结合Tomcat、JBoss等多种服务器，提供多种负载均衡、集群等功能实现，且当负载均衡节点超过8个时，仍然能够保持集群吞吐量的线性增长。 Eclipse插件地址： 下载地址： 至此，Apache + Tomcat成功完成，征服Apache系列暂告一段落！ 作为开博以来的第100帖，算是很成功了！ 测试应用见附件！