Apache+Tomcat整合

步骤：

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

1.安装Apache相关模块
负载均衡须要的主要是代理模块！
通过几回Apache配置尝试，在Ubuntu下配置Apache实在是太容易了。加载什么模块、取消什么模块两个命令搞定。

 #启用模块
 sudo a2enmod <model>
 #禁用模块
 sudo a2dismod <model>

这里，咱们须要让Apache提供代理服务，其中又包含基于http、ftp、ajp等等协议的代理功能，同时还须要负载均衡模块。咱们能够经过命令逐个加载：

 #代理核心模块
 sudo a2enmod proxy
 #代理AJP模块
 sudo a2enmod proxy_ajp
 #代理负载均衡模块
 sudo a2enmod proxy_balancer
 #代理HTTP模块
 sudo a2enmod proxy_http
 #代理FTP模块
 sudo a2enmod proxy_ftp

完成上述操做后，系统会提示重启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的关系相似，只是其中包含的是站点内容。

罗嗦了一堆，下面配置负载均衡部分。
执行修改：

 sudo vi /etc/apache2/mods-available/proxy.conf

上图红框中的内容是原始内容，白框中的内容是我新加的部分。
注意红框中的配置：

 <Proxy *>
         AddDefaultCharset off
         Order deny,allow
         #Deny from all
         Allow from localhost ip6-localhost
 </Proxy>

在默认配置中，Deny from all处于可用状态。当咱们配置其余代理节点时，将致使杜绝访问！使用 Allow from localhost ip6-localhost 限制仅容许本机访问！
再说，白框中的内容：

 <Proxy balancer://zlex>
         BalancerMember http://localhost:8080/
         BalancerMember http://192.168.49.1:8080/
 </Proxy>

这里，我配置了一个负载均衡节点 balancer://zlex，其中包含了两个服务 http://localhost:8080/和 http://192.168.49.1:8080/，一个是虚拟机上的Tomcat、一个是真机上的Tomcat。这里使用的Http的转发方式，固然，使用AJP何尝不可，稍后详述！
这里的节点次序会有一个前后关系，Apache会将请求按照FIFO的方式调度顺次分配到各个节点上！若是其中有一个节点挂掉，将跳过该节点顺次寻找可用节点。
再说代理和反向代理：

 ProxyPass /zlex balancer://zlex
 ProxyPassReverse /zlex balancer://zlex

这里配置，若是要访问 /zlex路径时，将跳转到 balancer://zlex上，也就是享受负载均衡！

2.后台监控
咱们如何知道某个节点负载多少，响应时间多久，服务是否正常呢？Apache提供了负载均衡监控平台： http://localhost/balancer-manager。可是，这个服务默认是不存在。
除了用于负载均衡配置、监控的 balancer-manager还有 http://localhost/server-status和 http://localhost/server-info
咱们须要添加info模块：

 #系统信息模块
 sudo a2enmod info

同时，为了可以使用 balancer-manager，咱们须要配置：

 <Location /balancer-manager>
         SetHandler balancer-manager
         Order Deny,Allow
         #Deny from all
         Allow from localhost ip6-localhost
 </Location>

把这段代码放到哪？因为它同属系统信息配置，我把它放到了 info.conf中，说白了就是照猫画虎：

 sudo vi /etc/apache2/mods-available/info.conf

注意，这段代码放到了 <IfModule mod_info.c>和 </IfModule>之间！
如今，咱们重启Apache：

 sudo /etc/init.d/apache2 restart

来看看管理界面 http://localhost/balancer-manager：


咱们再来看看服务器基本信息 http://localhost/server-info：


上述两个服务须要加载info模块，而服务器状态（server-status）不须要 http://localhost/server-status：


3.负载均衡简单测试
疯狂访问 http://localhost/zlex，直到手酸眼烦！
我这里故意使用不一样了Tomcat界面，来验证本身的配置是否生效。更疯狂的是，我甚至把节点指向了百度、搜狐，来测试负载均衡的效果。若是你细致观察，Apache是将请求顺次分配到各个节点上的。
若是其中一个节点发生问题（例如，强行关闭一个Tomcat，或配置一个错误节点）Apache将会通过几回尝试后，绕过这个问题节点，寻找能够成功访问的节点。若是这个节点恢复正常使用，Apache将在该Tomcat恢复正常工做后大约1分钟内将该节点标识为可用！
如今，再看看如今的后台（ http://localhost/balancer-manager）啥样子：

若是咱们控制一个节点的状态是否可用，该怎么作：

涉及到负载量，session同步等等，咱们最后讨论！

4.配置Tomcat相关模块（AJP）
基于Http协议分发并不复杂，但AJP效果更好！一次诡异事件中，内网访问正常，外网访问屡次失败，最后经过AJP方式完美解决了！
在Tomcat中配置AJP也很简单，修改 server.xml开启AJP模块：

 sudo vi /etc/tomcat6/server.xml

开启AJP配置：

 <Connector  port="8009" protocol="AJP/1.3"
                 URIEncoding="UTF-8"
                 redirectPort="8443" />

注意使用的端口port="8009"，字符集URIEncoding="UTF-8"，这是输入框、请求字符集乱码的入口！
接下里就能够经过AJP方式进行节点分发了。修改 /etc/apache2/mods-available/proxy.conf ：

 sudo vi /etc/apache2/mods-available/proxy.conf

将 http改成 ajp，将 8080改成 8009：

 <Proxy balancer://zlex>
         BalancerMember ajp://localhost:8009/
         BalancerMember ajp://192.168.49.1:8009/
 </Proxy>

重启Apache：

 sudo /etc/init.d/apache2 restart

再看看管理界面 http://localhost/balancer-manager

至此，咱们完成了基本负载均衡的基本配置！

/etc/apache2/mods-available/proxy.conf还有一些属性:
noFailOver是否打开失败转移， On| Off，默认为Off，添加在 ProxyPass后面，如：

 ProxyPass /zlex balancer://zlex  stickySession=JSESSIONID noFailOver=On

若是这样配置，当提供给你服务的服务器发生异常，那么你将一直看着它返回给你503，直到系统恢复正常！

loadfactor表示后台服务器负载到由Apache发送请求的权值,默认值为1添加在 BalancerMember后面：

 <Proxy balancer://zlex>
         BalancerMember ajp://localhost:8009/
         BalancerMember ajp://192.168.49.1:8009/
 </Proxy>

能够实现三种策略：

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

5.Session惟一，粘性会话
Apache已经能够轻松将内容处理的工做分配给各个Tomcat了！
固然，这还不够，Session仍是个问题！
WHY？
咱们来作一系列修改，来检测Session到底出现了什么问题！
先来改造Tomcat，修改 server.xml：

 sudo vi /etc/tomcat6/server.xml

修改 <Engine />节点，增长 jvmRoute属性：

 <Engine
              name="Catalina"
              defaultHost="localhost"
              jvmRoute="tomcat1">

另外一个Tomcat设置改成

 <Engine
              name="Catalina"
              defaultHost="localhost"
              jvmRoute="tomcat2">

经过 jvmRoute，指定了Tomcat惟一标识！
而后修改 /etc/apache2/mods-available/proxy.conf

 sudo vi /etc/apache2/mods-available/proxy.conf

以下：

 <Proxy balancer://zlex>
         BalancerMember ajp://localhost:8009/zlex     route=tomcat1
         BalancerMember ajp://192.168.49.1:8009/zlex        route=tomcat2
 </Proxy>

 ProxyPass /zlex balancer://zlex
 ProxyPassReverse /zlex balancer://zlex

这里须要经过修改 route属性，将Apache与Tomcat关联起来！
注意，Tomcat中定义的jvmRoute须要与Apache定义的route相对应！
咱们来看一下 http://localhost/balancer-manager发生了什么变化：

咱们注意到route字段有了新的标识，固然，咱们也能够经过这个配置界面修改这些信息，但当前修改不会真的修改/etc/apache2/mods-available/proxy.conf文件，Apache重启后将丢失。

为了更细致的对比进过复杂均衡的结果，这里增长了zlex应用！主要是监控Session的变化！
只看核心代码：

 <b>当前SessionID：</b>
 <br />
 <%
         String sessionID = session.getId();
         out.println(sessionID);
         System.err.println("sessionID = " + sessionID);

         // 若是有新的 Session 属性设置
         String dataName = request.getParameter("dataName");
         if (dataName != null && !dataName.isEmpty()) {
                 String dataValue = request.getParameter("dataValue");
                 session.setAttribute(dataName, dataValue);
         }
 %>
 <br />
 <br />
 <b>Session属性列表：</b>

 <br />
 <%
         Enumeration<String> e = (Enumeration<String>) session
                         .getAttributeNames();
         while (e.hasMoreElements()) {
                 String name = e.nextElement();
                 String value = (String) session.getAttribute(name);
                 out.println(name + " = " + value + "<br>");
                 System.err.println(name + " = " + value);
         }
 %>
 <form method="POST">
 <ul style="list-style-type: none;">
         <li><label for="dataName">键：</label><input size="20" id="dataName"
                 name="dataName"></li>
         <li><label for="dataValue">值：</label><input size="20"
                 id="dataValue" name="dataValue"></li>
         <li><input type="submit" value="提交" /></li>
 </ul>
 </form>

将其作成一个名为zlex的web应用，分别部署到两个Tomcat上！
而后重启Apache：

 sudo /etc/init.d/apache2 restart

不断刷新 http://localhost/zlex，看看真正的结果：
第1次：
第2次：
第3次：
第4次：
仔细观察，每次请求都按照负载均衡配置的节点次序依次请求到不一样的Tomcat上。尤为是当咱们经过 jvmRoute和 route作了绑定以后，信息更加准确。可是， 仔细观察，每次请求的SessionID都是不同！对于纯Web应用，尤为是依靠SessionID区分惟一用户的应用，这将是一场噩梦——解决了服务器压力均衡问题，却带来了SessionID不惟一问题！这就须要SessionID绑定，或者说叫作“会话复制”。
若是这时候你在页面上提交表单，将键值对保持在session中，在页面刷新后，将没法得到该信息，由于Seesion丢失了！
接着修改 /etc/apache2/mods-available/proxy.conf，让SeesionID保持惟一：

 sudo vi /etc/apache2/mods-available/proxy.conf

增长 stickySession属性：

 ProxyPass /zlex balancer://zlex  stickySession=JSESSIONID

stickySession粘性会话，根据这一属性，浏览器将经过cookie绑定SeesionID。若是这个时候再次访问 http://localhost/zlex，你会发现，页面不会来回跳转了！
sticky是什么？

引用

sticky模式
利用负载均衡器的sticky模式的方式把全部同一session的请求都发送到相同的Tomcat节点。这样不一样用户的请求就被平均分配到集群 中各个tomcat节点上，实现负载均衡的能力。这样作的缺点是没有灾难恢复的能力。一旦一个节点发生故障，这个节点上全部的session信息所有丢 失；
同一用户同一session只和一个webServer交互，一旦这个webserver发生故障，本次session将丢失，用户不能继续使用 !

提交一个Session设定看看 http://localhost/zlex：

观察后台日志：

再看看返回页面，这至关于一次页面刷新，若是正常粘性会话，咱们将得到当前SessionID对应的一切信息：

这说明粘性会话生效了！
咱们获得了形如

引用

50DAF14C6CDF8ACFBDC1095A5EE8E2CF.tomcat1

的SessionID。这样，咱们就能知道当前访问的是哪台服务器了！
若是，换一个浏览器打开该页面http://localhost/zlex，将会得到一个新的SessionID，而且，根据Apache中配置的负载均衡节点列表依次访问下一个节点！
若是这时候负载均衡节点列表中某一节点发生异常，那么Apache将按照惯例，跳转该节点，并在该节点恢复正常后约1分钟内从新将其归入可用节点！
修改刚才的jsp页面，看看Http头中都有些什么：

 <b>Cookie信息：</b>
 <br />
 ${header["cookie"]}
 <br />
 <b>Host信息：</b>
 <br />
 ${header["host"]}
 <br />

sticky模式的根本在于浏览器支持cookie，若是浏览器不支持cookie，则须要修改server.xml文件中的<Context />节点，将cookie置为false，关闭cookie功能，让jsessionid显式传递！

6.Tomcat集群，Session复制
通过两天反复研究，两只互不相认的Tomcat终于在网络上“资源共享”了——Session复制成功！
关于 Tomcat集群以及Session复制，网上已经有不少不少，可是否真的能用？！为了确认这一问题，周末还跑到书店翻了翻《Apache Tomcat 高级编程》，参考 Clustering/Session Replication HOW-TO（有点小错误），通过两天苦战，克服种种小问题，终于拿下！

整理概念：

引用

群集，是包含多个服务器实例的指定集合，这些服务器实例共享相同的应用程序、资源以及配置信息。您能够将不一样计算机上的服务器实例分组到一个逻辑群集中并将其做为一个单元来管理。您可使用 DAS 轻松控制多机群集的生命周期。

群集能够实现水平可伸缩性、负载平衡和故障转移保护。根据定义，群集中的全部实例都具备相同的资源和应用程序配置。当群集中的服务器实例或计算机 出现故障时，负载平衡器检测到该故障，会将通讯从出现故障的实例重定向至群集中的其余实例，并恢复用户会话状态。因为群集中全部实例上的应用程序和资源都 相同，所以一个实例能够故障转移至群集中的任何其余实例。

引用

Session复制，主要是指集群环境下，多台应用服务器之间同步Session，确保Session保持一致，且Session中的内容保持一致，对外透明——看起来就像是一台应用服务器！
若是其中一台服务器发生故障，根据负载均衡的原理，Apache会遍历寻找可用节点，分发请求。与此同时，当前用户Session不能发生数据丢失，其他各节点服务器应保证用户Session数据同步。

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文件：

 sudo vi /etc/apache2/mods-available/proxy.conf

修改负载均衡节点以下：

 <Proxy balancer://zlex>
         BalancerMember ajp://192.168.49.128:8009/zlex        route=tomcat1
         BalancerMember ajp://192.168.49.132:8009/zlex        route=tomcat2
 </Proxy>

对于windows系统，不须要考虑网络问题，广播地址（这里用到 224.0.0.0和 240.0.0.0）默认开放，对于linux则须要经过命令开放地址。
Ubuntu上开放广播地址（eth0网卡）：

 sudo route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0

而后经过 -v参数查看当前开放的广播地址：

 route -v

注意，重启后，该路由设置将丢失！

在Ubuntu下，能够考虑修改 /etc/networks文件！


若是有必要，Windows上开放广播地址（192.168.49.128本机地址）：

 route add 224.0.0.0 mask 240.0.0.0 192.168.49.128

而后经过 print参数查看当前开放的广播地址：

 route print

而后，修改tomcat的server.xml文件：

 sudo vi /etc/tomcat6/server.xml

在 <Engine /> 节点中加入以下内容：

   <Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"
          channelSendOptions="8">

   <Manager className="org.apache.catalina.ha.session.DeltaManager"
            expireSessionsOnShutdown="false"
            notifyListenersOnReplication="true"/>

   <Channel className="org.apache.catalina.tribes.group.GroupChannel">
     <Membership className="org.apache.catalina.tribes.membership.McastService"
                 address="224.0.0.0"
                 port="45564"
                 frequency="500"
                 dropTime="3000"/>
     <Receiver className="org.apache.catalina.tribes.transport.nio.NioReceiver"
               address="192.168.49.1"
               port="4000"
               autoBind="100"
               selectorTimeout="5000"
               maxThreads="6"/>

     <Sender className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
       <Transport className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>
     </Sender>
     <Interceptor className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
     <Interceptor className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/>
   </Channel>

   <Valve className="org.apache.catalina.ha.tcp.ReplicationValve"
          filter=".*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;"/>
   <Valve className="org.apache.catalina.ha.session.JvmRouteBinderValve"/>

   <ClusterListener className="org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener"/>
   <ClusterListener className="org.apache.catalina.ha.session.ClusterSessionListener"/>
 </Cluster>

这里须要注意 <Membership />和 Receiver： <Membership />节点的 address属性是广播地址； Receiver节点的 address属性是本地绑定地址。固然，默认为 auto。因为我在启动Tomcat时，Tomcat频频将地址指向 127.0.0.1，无奈只好使用固定IP。
此外，为了下降Session复制的成本，Tomcat经过 <Valve />节点，以过滤器的方式控制哪些请求能够忽略Session复制：

 <Valve className="org.apache.catalina.ha.tcp.ReplicationValve"
        filter=".*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;"/>

同时，在<Host>节点中加入以下内容：

 <Deployer className="org.apache.catalina.ha.deploy.FarmWarDeployer"
           tempDir="/tmp/war-temp/"
           deployDir="/tmp/war-deploy/"
           watchDir="/tmp/war-listen/"
           watchEnabled="false"/>

在Tomcat的官方文档（Tomcat 6）中，对于<Deployer  />节点的部署位置是错误的，经过观察Tomcat启动日志，确认该节点应当不属于<Host />节点中！

注意：Tomcat 6与Tomcat5在上述节点中使用的类包（包中名称由cluster变化为ha）有所不一样，且结构有所调整。

先别急着重启，咱们须要修改应用中的 web.xml文件，将 <distributable />节点部署到 <web-app />节点中，开启分布式服务：


注意：若是没有设置该节点，SessionID将不能保持同步，不一样的服务器将各自创建独立的SessionID！

监控Tomcat日志：

 tail -f /var/lib/tomcat6/logs/catalina.out

而后重启Tomcat1：

 sudo /etc/init.d/tomcat6 restart

观察日志：

注意两处红框：
第一处，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成员直接会每隔一个时间段相互侦测/验证其余成员是否正常：


如今，开始访问 http://localhost/zlex，并不断刷新当前页面：

除了两处标识主机来源的tomcatX不一样外，session是彻底一致的！
提交一次修改，并不断刷新当前页：

若是仔细观察，当前SessionID在不断交替变化，这说明负载均衡在起做用！
咱们再来看看2个Tomcat后台日志都作了什么！
Tomcat1：

Tomcat2：
两只猫都打印了相同的内容（ a=1）不一样的细节在于，sessionID带有服务器标识！

若是咱们强行关闭Tomcat2：
首先，Tomcat1会很快侦测到Tomcat2离线，由于这是TCP通信，成员之间很容易检测到其余成员是否离线！Tomcat1后台日志以下：

其次，Apache会侦测到Tomcat2发生异常，将其他请求转交给其余节点，即交由Tomcat1处理！
继续刷新 http://localhost/zlex当前页面，耐心等待几秒。你会发现，即使再次刷新页面，sessionID仍旧绑定在标识tomcat1服务器上。
而后，咱们恢复Tomcat2服务，Tomcat1会立刻侦测到Tomcat2已经恢复正常：

最后，咱们再次刷新当前页，Apache已经将请求分发给Tomcat2了，从后台日志能够看到session信息会很快被同步了！

若是带有tomcatX标识的sessionID有不少不便之处，能够关闭粘性会话。简单的讲，就是取消Tomcat中[b]server.xml中 <Engine/ >节点的 jvmRoute属性！[/b]而后，重启tomcat、apache！

页面提交一个 b=3！

左边为Tomcat1，右边为Tomcat2！SessionID一致！

除了上述几种方案外，还有 Terracotta模式。一种第三方集群组件，2009年收购了缓存组件EhCache，能够结合Tomcat、JBoss等多种服务器，提供多种负载均衡、集群等功能实现，且当负载均衡节点超过8个时，仍然可以保持集群吞吐量的线性增加。
Eclipse插件地址：
http://download.terracotta.org/eclipse/update
下载地址：
http://www.terracotta.org/dl/oss-download-catalog

至此，Apache + Tomcat成功完成，征服Apache系列暂告一段落！
做为开博以来的第100帖，算是很成功了！

测试应用见附件！