Tomcat集群Cluster实现原理剖析

1、对于WEB应用集群的技术实现而言，最大的难点就是如何 能在集群中的多个节点之间保持数据的一致性，会话( Session )信 息是这些数据中最重要的一 块。要实现这一点， 大体上有两种方式， 一种是把所有 Session 数据放到一台服务器上或者数据库中， 集群中 的所有节点通过访问这台 Session 服务器 来获取数据；另一种就是 在集群中的所有节点间进行 Session 数据的同步拷贝， 任何一个节点 均保存了所有的 Session 数据。两种方式都各有优点，第 一种方式 简单、易于实现， 但是存在着 Session 服务器发生故障会导致全系统 不能正常工作的风险； 第二种方式可靠性更高

2、， 任一节点的故障不会 对整个系统 对客户访问的响应产生影响，但是技术实现上更复杂一 些。常见的平台或中间件如 microsoft 和IBM WAS都会提供对两种 共享方式的支持， tomcat 也是这样，但是一般采用第二种方式。当采用 tomcat 默认集群配置(vCluster className二/) 时，配置的细节实际上被 省略了，对于大多数应用而言，使用默认 配置已经足够，完整的默认配置应该是这样：0000/Membership className= address= port=45564 frequency=5dropTime=30下面笔者对这里的配置项作详细解释，以下内容均是笔者

3、 阅读了 tomcat 官方文档后自己的理解，有些可能不对，希望读者能 带着批判的眼光阅读，并欢迎指正笔者错误。tomcat 集群各节点通过建立 tcp 链接来完成 Session 的拷 贝，拷贝有同步和异步两种模式。在同步模式下，对客户端的响应必 须在 Session 拷 贝到其他节点完成后进行；异步模式无需等待 Session 拷贝完成就可响应。异步模式更高效，但是同步模式可靠性 更高。同步异步模式由 channelSendOptions 参数控制， 默认值是 8， 为异步模式， 4 是同步模式。在异步模式下，可以通过加上拷贝确认 (Acknowledge) 来提高可靠性， 此时 chan

4、nelSendOptions 设为 10。Manager 用来在节点间拷贝 Session ，默认使用 DeltaManager ，DeltaManager 采用的一种 all-to-all的工作方 式，即集群中的节点会把 Session 数据向所有其他节点拷贝， 而不管其他节点是否部署了当前应用。 当集群中的节点数量很多并且部署着不同 应用时，可以使 用BackupManage, BackManager仅向部署了当前应 用的节点拷贝Session。但是到目前为止BackupManager并未经过 大 规模测试，可靠性不及 DeltaManager。Channel负责对tomcat集群的10层

5、进行配置。Membership 用于发现集群中的其他节点，这里的 address 用的是组播地址（Multicast address，了解更多组播地址详情请参见），使用同一个组播地址和端口的多个节点同属一个子集群， 因此通过自定义组播 地址和端口就可将一个大的 tomcat 集群分成多个子集群。 Receiver 用于 各个节点接收其他节点发送的数据， 在默认配置下 tomcat 会从 4000-4100 间依次选取一个可用的端口进行接收，自定义配置时，如 果多个 tomcat 节点在一台物理服务器上注意要使用不同的端口。 Sender 用于向其他节点发送数据，具体实现通过 Transport

6、 配 置， PooledParallelSender 是从 tcp 连接池中获取连接，可以实现并行 发送，即集群中的多个节点可以同时向其他所有节点发送数据而互不 影响。Interceptor 有点类似下面将要解释的 Valve，起到一个阀门 的作用，在数据到达目的节点前进行检测或其他操作，如 TcpFailureDetector 用于检测在数据的传输过程中是否发生了 tcp 错误。关于 Channel 的编程模型，请参见。Valve 用于在节点向客户端响应前进行检测或进行某些操 作， ReplicationValve 就是用于用于检测当前的响应是否涉及 Session 数据的 更新，如果是则启

7、动 Session 拷贝操作， filter 用 于过滤请求，如客户端对图片， css ，js 的请求就不会涉及 Session ， 因此不需检测，默 认状态下不进行过滤，监测所有的响应。 JvmRouteBinderValve 会在前端的 Apache mod_jk 发生错误时保证同 一客户端的请求发送到集群的同一个节点， tomcat 官方文档并未解 释如何实现这一点，而且笔者认为这一设置似乎并无多大实 用性。Deployer 用于集群的 farm 功能，监控应用中文件的更新， 以保证集群中所有节点应用的一致性， 如某个用户上传文件到集群中 某个节点的应用程序目录 下，Deployer会监

8、测到这一操作并把这一 文件拷贝到集群中其他节点相同应用的对应目录下以保持所有应用 的一致。这是一个相当强大的功能，不过很遗 憾， tomcat 集群目前 并不能做到这一点， 开发人员正在努力实现它， 这里的配置只是预留 了一个接口。Listener 用于跟踪集群中节点发出和收到的数据，也有点类 似 Valve 的功能。在大体了解了 tomcat 集群实现模型后， 就可以对集群作出更 优化的配置了， tomcat 推荐了一套配置，使用了比 DeltaManager 更 高效的BackupManager,并且对ReplicationValve 设置了请求过滤， 注意在一台服务器部署多个节点时需要修

9、改 Receiver 的侦听端 口， 另外,为了更高效的在节点间拷贝数据,所有 tomcat 节点最好采用 相同的配置,具体配置如下：Tomcat 集群除了可以进行 Session 数据的拷贝，还可进行 Context 属性的拷贝，通过修改的 Context 配置可以实 现，使用 替换默认 Context 即可，当然也可再加上 distributable=true 属性。下面通过假想的一组场景来描述 tomcat 集群如何工作， 集 群采用默认配置，由 t1 和 t2 两个 tomcat 例程组成，场景按照时间 顺序排列。t1 启动t1 按照标准的 tomcat 启动，当 Host 对象被创建

10、时，一个 Cluster 对象（默认配置下是 SimpleTcpCluster ）也同时被关联到这 个Host对象。当某个应用在中设置了 distributable 时，Tomcat将 为此应用的上下文环境创建一个 DeltaManager 。 SimpleTcpCluster 启动membership服务和Replication 服务（用于建立tcp连接）。t2 启动（待 t1 启动完成后）首先 t2 会执行和 t1 一样的操作，然后 SimpleTcpCluster 会建立一个由t1和t2组成的membership接着t2向集群中已启动 的服 务器即 t1 请求 Session 数据，如果

11、 t1 没有响应 t2 的拷贝请求， t2 会在 60 秒后 time out 。在 Session 数据拷贝完成之前 t2 不会接 收客户端的 http 或 mod_jk/ajp 请求。t1 接收 http 请求，创建 Session s1t1 正常响应客户请求，但是在 t1 把结果发送回客户端时，ReplicationValve 会拦截当前请求（如果 filter 中配置了不需拦截 的请求类 型，这一步就不会进行，默认配置下拦截所有请求），如 果发现当前请求更新了 Session ，调用 Replication 服务建立 tcp 连 接把 Session 拷贝到 membership 列表

12、中的其他节点即 t2 ，返回结果 给客户端（注意， 如果采用同步拷贝，必须等拷贝完成后才会返回结 果，异步拷贝 在数据发送到 tcp 连接就返回结果，不等待拷贝完成）。 在拷贝时，所有保存在当前 Session 中的可序列化的对象都会被拷 贝，而不仅仅是发生更新的部 分。t1 崩溃当 t1 崩溃时， t2 会被告知 t1 已从集群中退出，然后 t2 就会把 t1 从自己的 membership 列表中删除，发生在 t2 的 Session 更新不再往 t1 拷贝，同时负载均衡器会把后续的 http 请求全部转发 给 t2 。在此过程中所有的 Session 数据不会丢失。t2 接收 s1 的请求t2 正常响应 s1 的请求，因为 t2 保存着 s1 的所有数据。t1 重新启动按步骤 1、2 一样的操作启动，加入集群，从 t2 拷贝所有Session 数据，拷贝完成后开放自己的 http 和 mod_jk/ajp 端口接收 请求。t1 接收请求， s1 失效t1 继续接收来自 s1 的请求，把 s1 设置为过期。这里的过 期并非因为 s1 处于非活动状态超过设置的时间，而是执行类似注销 的操作而引起的 Session 失 效。这时 t1 并非发送 s1 的所有数据而 是一个类似 s1 expired 的消