概述
本文是企业高可用架构之一：APACHE+TOMCAT实现高可用WEB集群。
Apache+tomcat是J2EE领域最常见和低成本的高可用集群实现方式，同时也是应用最广泛的WEB-HA实现方式之一。本文结合工作经验和学习所得，简单介绍APACHE+TOMCAT集群的各种使用方式，并进行简单对比。当然，干这行都知道，架构选择就像找老婆：没有最好的，只有最合适的。
目标：
支持故障转移（或主备，扩展性不佳），保证故障转移后，对前端用户透明，无感知（状态不变化），同时为提高性能支持复制均衡。
APACHE主要负责：负载均衡（LoadBalancer），故障转移（Failover）,主备（指TOMCAT的主备，一般没有使用）
TOMCAT负责：SESSION复制和SESSION共享
散装介绍
以下散装介绍，是想到什么写什么，没有特别的梳理，主要介绍些关键的概念和逻辑。
APACHE最为最老牌的WEB服务器，提供了2种方式与TOMCAT实现集群。Mod_jk和proxy。Mod_jk配置较复杂，一般是老版本在使用，目前一般常用的是proxy方式，本文以proxy进行介绍。
Proxy是APACHE提供的代理网关模块，支持http,ftp等多种协议的正向和反向代理。
请参考官方文档： http://httpd.apache.org/docs/2.2/mod/mod_proxy.html
关于正向代理和返现代理请参考：http://zp820705.iteye.com/blog/1337414
Apache_proxy通过反向代理与TOMCAT结合，包括以下几种方式：
http直接代理
支持负载均衡，支持failover，不支持粘性会话（sticky session，我没有测试通过）
ajp代理
支持负载均衡，支持failover，支持粘性会话（sticky session）
PROXY代理负载均衡算法：
参数：lbmethod
lbmethod=byrequests 按照请求次数均衡(默认)
lbmethod=bytraffic 按照流量均衡
lbmethod=bybusyness 按照繁忙程度均衡(总是分配给活跃请求数最少的服务器)
proxy 故障转移
参数：nofailover
Off 默认，表示支持
On 表示不支持
sticky session
参数：stickysession
参数值：根据后端服务器的SESSION的ID字段名称配置，COOKIES|[URL]，前部分表示COOKIES方式，后面部分表示不支持COOKIES的客户端使用的URL方式的字段名称。
TOMCAT配置一般为：JSESSIONID|jsessionid
sticky session中文叫粘性会话，实现一个用户的同一会话的多次请求使用同一台后端服务器支持，简答的说就是前端用户通过浏览器打开界面到关闭浏览器之间的所有请求都由一台TOMCAT服务，这种方式只实现了会话级别的负载均衡。APACHE+TOMCAT的sticky session一般通过AJP方式代理。
1. 用户首次请求APACHE时，APACHE通过负载均衡算法找出服务的后端TOMCAT服务器，修改SESSIONID为SESSIONID.route，route表示后端TOMCAT的唯一标志。
2. 在TOMCAT处理完成后，RESPONSE（SET-COOKIES）给客户端浏览器。
3. 客户端浏览器下次请求的时候带上该SESSIONID，APACHE通过请求中的SESSIONID的route选择对应的后端TOMCAT进行服务，实现复制均衡的同时保证SESSION可以。
缺点：
一点正在服务的后端TOMCAT宕机，那么改用户的SESSION丢失。
解决：
TOMCAT使用会话复制或会话共享。
TOMCAT：
是否需要使用SESSION？
一般对应前端应用型的网站或管理系统是需要SESSION来保存当前用户的状态的，对应以HTTP（如REST,SOAP等）协议为基础提供接口或服务的系统，因为每次请求都是原子的，不用考虑SESSION的问题。
如果不需要SEESION，TOMCAT端配置很简单，根据APACHE端的代理选择，如果是HTTP直接代理，那么TOMCAT无需任何其他集群相关配置；如果是AJP方式，需要分别在各个TOMCAT的server.xml文件中的< Engine>节点增加属性jvmRoute，设置APACHE端配置的对应的标志,如：<Engine name="Catalina" defaultHost="localhost" jvmRoute="tomcat1">
session复制
session复制解释起来很简单，就是一旦一个TOMCAT节点产生了SESSION，就复制到其他TOMCAT节点，保证由于前段APACHE负载均衡分发用户请求道其他节点时，能正常使用SESSION。
TOMCAT默认的集群方式就是使用多播进行SESSION复制，但是消耗很大，在2台TOMCAT组成的集群效果还可以，但是节点越多消耗越大，效率越低。这也是业内称这种方案为实验室方案的原因。
支持通过和异步方式的SESSION复制，也支持持久化SESSION到公共存储或数据库（我没有测试过，只是官方文档上提到过）
参考官方文档：http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html
可以与sticky session结合。
session共享
session共享是TOMCAT服务器只创建一次SESSION，保存到共享设备（磁盘，数据库，或公共缓存），与其他节点共享SESSION访问，要求保证并发情况下的事务性，实现任意节点宕机后，其他节点可以正常的继续为前端用户服务。相对SESSION复制，消耗小很多，性能较高，特别对横向扩展TOMCAT节点支持较好。应用最广的是使用分布式缓存系统memcached保存TOMCAT会话。
开源组件：memcached session manager(msm)提供了完整TOMCAT共享存储SESSION到memcached的实现，并提供了多种方式和序列话模式。
如果前端apache的负载均衡使用sticky session方式，msm可以支持memcached的主备，保证memcached的高可用。如果你需要确保SESSION的高可用的话，这是一个不错的选择。
参考：http://code.google.com/p/memcached-session-manager/wiki/SetupAndConfiguration
APACHE+TOMCAT 的HA方案
方案一： APACHE_proxy_http代理 + TOMCAT实现平台接口服务
特点：
1. 作为平台接口服务，不考虑SESSION相关问题，每次请求都是原子操作。
2. APACHE作为负载均衡和故障转移，负载均衡不使用stickysession,算法可以根据实际情况选择，2.2后选择bybusiness较好。
3. TOMCAT需做任务特殊的配置
注意：
如果TOMCAT节点需要使用重定向（307）到TOMCAT直接访问则删除ProxyPassReverse配置。一般情况是TOMCAT节点有大IO操作可以使用307重定向到TOMCAT节点IP（独立IP和带宽）和端口，分离大数据流和业务流
ProxyPassReverse指令请参考：http://zp820705.iteye.com/blog/1337414
详细配置：http://zp820705.iteye.com/blog/1347417
方案二： APACHE(proxy_ajp_stickysession) + TOMCAT实现高可用网站或管理系统集群
l 使用sticky session实现会话级别的负载均衡和故障转移
l TOMCAT不做SESSION的复制或共享，一旦节点宕机或失效，改节点当前服务的所有用户SESSION丢失
对于对SESSION丢失影响不大的系统可以考虑，配置简单，资源消耗小，一定程度上实现高可用。如：内部管理系统（非营运系统）比较适合
详细配置：http://zp820705.iteye.com/blog/1377732
方案三： APACHE(proxy) + TOMCAT(session复制)实现高可用网站或管理系统集群
l Apache端可选使用sticky session配置负载均衡，是否配置sticky只是影响负载均衡的粒度。
l Apache端配置故障转移.
l Tomcat端使用官方文档描述的cluster配置，通过多播实现内存方式的session复制，可选使用同步复制和异步复制。
对于对SESSION强依赖的系统，并且对系统处理能力要求不是太高，只考虑2台TOMCAT作为后端服务的主备方式的情况，这是一种简答的配置。不适合太多的TOMCAT节点，节点越多，复制SESSION的代价会几何方式增加。如：适合小型网站，管理系统，小型业务系统。
详细配置：http://zp820705.iteye.com/blog/1377754
方案四： APACHE(proxy_ajp_stickysession) + TOMCAT(msm_sticky)实现HA
l Apache端使用AJP方式连接后端TOMCAT，启用sticky，实现会话级别的负载均衡。
l APACHE端配置支持后端TOMCAT节点的故障转移。
l 可选的APACHE通过keepalived实现2台apache的主备配置，实现apache服务器的高可用
l TOMCAT端使用memcached session manager实现SESSION的共享存储和访问。
l memcached session manager采用sticky方式配置，实现memcached的failover，确保memcached高可用。
该方案主要可以用于中型或大型WEB系统。在架构的各层都考虑了高可用。是比较完善的廉价解决方案之一。可以支持多个TOMCAT节点，对TOMCAT节点的扩容的非常方便。可以使用在对可靠性要求比较高的WEB业务系统，如对外业务支撑，业务处理系统，中大型业务型网站等。
详细配置：http://zp820705.iteye.com/blog/1377785
方案五： APACHE(proxy) + TOMCAT(msm_nosticky)实现HA
本方案与方案4类似，不同之处在于msm使用noticky方式，没有对memcached考虑failover。对于对SESSION可靠性要求不是特别高的WEB系统（其实也蛮高的可靠性了）可以采用该方案。比较适合内容型网站（如：新闻内网站，丢了SESSION问题不大，只要可以继续访问就OK）。