标签：
为什么要使用集群？主要有两方面原因：一是对于一些核心系统要求长期不能中断服务，为了提供高可用性我们需要由多台机器组成的集群；另外一方面，随着访问量越来越大且业务逻辑越来越复杂，单台机器的处理能力已经不足以处理如此多且复杂的逻辑，于是需要增加若干台机器使整个服务处理能力得到提升。
如果说一个web应用不涉及会话的话，那么做集群是相当简单的，因为节点都是无状态的，集群内各个节点无需互相通信，只需要将各个请求均匀分配到集群节点即可。但基本所有web应用都会使用会话机制，所以做web应用集群时整个难点在于会话数据的同步。
当然你可以通过一些策略规避复杂的额数据同步操作，例如前面说到的把会话信息保存在分布式缓存或数据库中统一集中管理，如下图，每个tomcat实例只需去写入或读取数据库即可，避免了tomcat集群之间的通信。但这种方式也有不足，要额外引入数据库或缓存服务，同时也要保证它们的高可用性，增加了机器和维护成本。
鉴于统一将会话存放到数据库或缓存上存在的不足，提供另一种解决思路就是tomcat集群节点自身完成各自的数据同步，不管访问到哪个节点都能找到对应的会话，如下图，客户端第一次访问生成会话，tomcat自身会将会话信息同步到其他节点上，而且是每次请求完成都会同步此次请求过程中对session的所有操作，这样一来下一次请求到集群中任意节点都能找到响应的会话信息，且能保证信息的及时性。而且任意一个节点宕掉了也不影响整体对外的服务。
Tomcat提供的第二种集群会话管理的机制就是单节点备份机制，下面看看这种方式具体的工作机制，集群一般是通过负载均衡对外提供整体服务，所有节点被隐藏在后端组成一个整体。前面各种模式的实现都无需负载均衡协助，所以图中都把负载均衡省略了。最常见的负载方式是前面用apache拖所有节点，它支持将类似“326257DA6DB76F8D2E38F2C4540D1DEA.tomcat1”的会话id进行分解，定位到tomcat集群中以tomcat1命名的节点上（这种方式称为Session Stick，由apache jk模块实现）。每个会话存在一个原件和一个备份，且备份与原件不会保存在同一个节点上，如下图，例如当客户端发起请求后通过负载均衡被分发到tomcat1实例节点上，生成一个包含.tomcat1后缀的会话标识，并且tomcat1节点根据一定策略选出此次会话对象备份的节点，然后将包含了{会话id，备份ip}的信息发送给tomcat2、tomcat3、tomcat4，如图中虚线所示，这样每个节点都有一个会话id、备份ip列表，即每个节点都有每个会话的备份ip地址。
完成上面一步后就是将会话内容备份到备份节点上，假如tomcat1的s1、s2两个会话的备份地址为tomcat2，则把会话对象备份到tomcat2中，类似的有tomcat2把s3会话备份到tomcat4，tomcat4把s4、s5两个对话备份到tomcat3，这样集群中所有的会话都已经有了一份备份。当tomcat1一直不出故障，由于Session Stick技术客户端将一直访问到tomcat1节点上，保证一直能获取到会话。而当tomcat1出故障了，这时tomcat也提供了一个failover机制，apache感知到后端集群tomcat1节点被移除了，这时它会把请求随机分配到其他任意节点上，接下去会有两种情况：
①刚好分到了备份节点tomcat2上，此时仍能获取到s1会话，除此之外，tomcat2还要另外做的事是将这个s1会话标记为原件且继续选取一个备份地址备份s1会话，这样一来又有了备份。
②假如分到了非备份节点tomcat3，此时肯定找不到s1会话，于是它将向集群所有节点发问，“请问谁有s1会话的备份ip地址信息？”，因为只有tomcat2有s1的备份地址信息，它接收到询问后应答告知tomcat3节点s1会话的备份在tomcat2，根据这个信息就能查到s1会话了，并且tomcat3在自己本地生成s1会话并标为原件，tomcat2上的副本不变，这样一来同样能找到s1会话，正常完整整个请求处理。
以上两种模型都有各自的优缺点，在实际生产上部署应该根据实际情况选择适合的模型。
对于全节点会话同步模型
细看很容易发现集群的节点之间的会话是两两互相复制的，一旦集群节点数量及访问量大起来，将导致大量的会话信息需要互相复制同步，很容易导致网络阻塞，而且这些同步操作很可能会成为整体性能的瓶颈，根据经验，此种方案在实际生产上推荐的集群节点个数为3-6个，它无法组建更大的集群，而且冗余了大量的数据，利用率较低。
对于集群增量会话管理器，可通过配置server.xml文件使用它，在tomcat中使用集群模式需要在<Engine>节点下添加<cluster>节点，而集群增量会话管理器正是在此节点下添加一个子节点<Manager className="org.apache.catalina.ha.session.DeltaManager"/>。
对于会话备份模型
针对上面全节点会话同步模型的网络流量随节点数量增加呈平方趋势增长的问题，也正是因为这个因素导致无法构建较大规模的集群，为了使集群节点能更加大，首要解决的就是数据复制时流量增长的问题，tomcat提出会话备份模型对前面的模型进行优化，它使会话备份的网络流量随节点数量的增加呈线性趋势增长，每个会话只会有一个备份，大大减少了网络流量和逻辑操作，此模型可构建较大的集群。生产上可以组成十个以上的节点作为一个集群。
对于集群备份会话管理器，可通过配置server.xml文件使用它，它的配置与DeltaManager的配置基本相似，在<cluster>节点下添加一个子节点<Manager className="org.apache.catalina.ha.session.BackupManager"/>。
使用这种模型也要考虑到，虽然这种模式支持更大的集群，但它只有一个数据备份，假如刚好源数据和备份数据所在的机器同时宕掉了，则没办法恢复数据，不过刚好同时宕机的机率很小很小。
喜欢java的同学交个朋友：
标签：
原文地址：http://blog.csdn.net/wangyangzhizhou/article/details/50615718
