Tomcat集群Cluster实现原理剖析.pdf

本文意在介绍对tomcat集群进行更深入详细的配置以满足特定需求。对于 WEB 应用集群的技术实现而言，最大的难点就是如何能在集群中的多个节点之间保持数据的一致性，会话（Session）信息是这些数据中最重要的一 块。要实现这一点，大体上有两种方式，一种是把所有 Session 数据放到一台服务器上或者数据库中，集群中的所有节点通过访问这台 Session 服务器 来获取数据；另一种就是在集群中的所有节点间进行 Session 数据的同步拷贝，任何一个节点均保存了所有的 Session 数据。两种方式都各有优点，第 一种方式简单、易于实现，但是存在着 Session 服务器发生故障会导致全系统不能正常工作的风险；第二种方式可靠性更高，任一节点的故障不会对整个系统 对客户访问的响应产生影响，但是技术实现上更复杂一些。常见的平台或中间件如 microsoft 和 IBM WAS 都会提供对两种共享方式的支持，tomcat 也是这样，但是一般采用第二种方式。当采用 tomcat 默认集群配置（）时，配置的细节实际上被 省略了，对于大多数应用而言，使用默认配置已经足够，完整的默认配置应该是这样：下面笔者对这里的配置项作详细解释，以下内容均是笔者阅读了tomcat 官方文档后自己的理解，有些可能不对，希望读者能带着批判的眼光阅读，并欢迎指正笔者错误。tomcat 集群各节点通过建立 tcp 链接来完成 Session 的拷贝，拷贝有同步和异步两种模式。在同步模式下，对客户端的响应必须在Session 拷 贝到其他节点完成后进行；异步模式无需等待 Session 拷贝完成就可响应。异步模式更高效，但是同步模式可靠性更高。同步异步模式由 channelSendOptions 参数控制，默认值是 8，为异步模式，4 是同步模式。在异步模式下，可以通过加上拷贝确认（Acknowledge）来提高可靠性，此时 channelSendOptions 设为 10。Manager 用来在节点间拷贝 Session，默认使用 DeltaManager，DeltaManager 采用的一种 all-to-all 的工作方 式，即集群中的节点会把 Session 数据向所有其他节点拷贝，而不管其他节点是否部署了当前应用。当集群中的节点数量很多并且部署着不同应用时，可以使 用BackupManager，BackManager 仅向部署了当前应用的节点拷贝Session。但是到目前为止 BackupManager 并未经过 大规模测试，可靠性不及 DeltaManager。Channel 负责对 tomcat 集群的 IO 层进行配置。Membership 用于发现集群中的其他节点，这里的 address 用的是组播地址（Multicast address，了解更多组播地址详情请参见），使用同一个组播地址和端口的多个节点同属一个子集群，因此通过自定义组播地址和端口就可将一个大的 tomcat 集群分成多个子集群。Receiver 用于 各个节点接收其他节点发送的数据，在默认配置下 tomcat 会从 4000-4100 间依次选取一个可用的端口进行接收，自定义配置时，如果多个 tomcat节点在一台物理服务器上注意要使用不同的端口。Sender 用于向其他节点发送数据，具体实现通过 Transport 配 置，PooledParallelSender是从 tcp 连接池中获取连接，可以实现并行发送，即集群中的多个节点可以同时向其他所有节点发送数据而互不 影响。Interceptor 有点类似下面将要解释的 Valve，起到一个阀门的作用，在数据到达目的节点前进行检测或其他操作，如 TcpFailureDetector 用于检测在数据的传输过程中是否发生了 tcp 错误。关于 Channel 的编程模型，请参见。Valve 用于在节点向客户端响应前进行检测或进行某些操作，ReplicationValve 就是用于用于检测当前的响应是否涉及 Session 数据的 更新，如果是则启动 Session 拷贝操作，filter 用于过滤请求，如客户端对图片，css，js 的请求就不会涉及 Session，因此不需检测，默 认状态下不进行过滤，监测所有的响应。JvmRouteBinderValve 会在前端的Apache mod_jk发生错误时保证同一客户端的请求发送到集群的同一个节点，tomcat 官方文档并未解释如何实现这一点，而且笔者认为这一设置似乎并无多大实 用性。Deployer 用于集群的 farm 功能，监控应用中文件的更新，以保证集群中所有节点应用的一致性，如某个用户上传文件到集群中某个节点的应用程序目录 下，Deployer 会监测到这一操作并把这一文件拷贝到集群中其他节点相同应用的对应目录下以保持所有应用的一致。这是一个相当强大的功能，不过很遗 憾，tomcat 集群目前并不能做到这一点，开发人员正在努力实现它，这里的配置只是预留了一个接口。Listener 用于跟踪集群中节点发出和收到的数据，也有点类似 Valve的功能。在大体了解了 tomcat 集群实现模型后，就可以对集群作出更优化的配置了，tomcat 推荐了一套配置，使用了比 DeltaManager 更高效的 BackupManager，并且对 ReplicationValve 设置了请求过滤，注意在一台服务器部署多个节点时需要修改 Receiver 的侦听端 口，另外，为了更高效的在节点间拷贝数据，所有 tomcat 节点最好采用相同的配置，具体配置如下：Tomcat 集群除了可以进行 Session 数据的拷贝，还可进行 Context属性的拷贝，通过修改的 Context 配置可以实 现，使用替换默认 Context 即可，当然也可再加上distributable=true属性。下面通过假想的一组场景来描述 tomcat 集群如何工作，集群采用默认配置，由 t1 和 t2 两个 tomcat 例程组成，场景按照时间顺序排列。1.t1 启动 t1 按照标准的 tomcat 启动，当 Host 对象被创建时，一个 Cluster对象（默认配置下是 SimpleTcpCluster）也同时被关联到这个 Host 对象。当某个应用在中设置了 distributable 时，Tomcat 将为此应用的上下文环境创建一个 DeltaManager。SimpleTcpCluster 启动 membership服务和 Replication 服务（用于建立 tcp 连接）。2.t2 启动（待 t1 启动完成后）首先 t2 会执行和 t1 一样的操作，然后 SimpleTcpCluster 会建立一个由 t1 和 t2 组成的 membership。接着 t2 向集群中已启动的服 务器即 t1 请求 Session 数据，如果 t1 没有响应 t2 的拷贝请求，t2 会在 60秒后time out。在Session数据拷贝完成之前t2不会接收客户端的http或 mod_jk/ajp 请求。3.t1 接收 http 请求，创建 Session s1 t1 正常响应客户请求，但是在 t1 把结果发送回客户端时，ReplicationValve 会拦截当前请求（如果 filter 中配置了不需拦截的请求类 型，这一步就不会进行，默认配置下拦截所有请求），如果发现当前请求更新了 Session，调用 Replication 服务建立 tcp 连接把 Session 拷贝到 membership 列表中的其他节点即 t2，返回结果给客户端（注意，如果采用同步拷贝，必须等拷贝完成后才会返回结果，异步拷贝 在数据发送到 tcp 连接就返回结果，不等待拷贝完成）。在拷贝时，所有保存在当前 Session 中的可序列化的对象都会被拷贝，而不仅仅是发生更新的部 分。4.t1 崩溃 当 t1 崩溃时，t2 会被告知 t1 已从集群中退出，然后 t2 就会把 t1从自己的 membership 列表中删除，发生在 t2 的 Session 更新不再往t1 拷贝，同时负载均衡器会把后续的 http 请求全部转发给 t2。在此过程中所有的 Session 数据不会丢失。5.t2 接收 s1 的请求 t2 正常响应 s1 的请求，因为 t2 保存着 s1 的所有数据。6.t1 重新启动 按步骤 1、2 一样的操作启动，加入集群，从 t2 拷贝所有 Session数据，拷贝完成后开放自己的 http 和 mod_jk/ajp 端口接收请求。7.t1 接收请求，s1 失效 t1 继续接收来自 s1 的请求，把 s1 设置为过期。这里的过期并非因为 s1 处于非活动状态超过设置的时间，而是执行类似注销的操作而引起的 Session 失 效。这时 t1 并非发送 s1 的所有数据而是一个类似 s1 expired 的消息，t2 收到消息后也会把 s1 设为过期。8.t2 接收请求，创建 Session s2 和步骤 3 一样。9.t1 s2 过期 对于因超时引起的 Session 失效 t1 无需通知 t2，因为 t2 同样知道s2 已经超时。因此对于 tomcat 集群有一点非常重要，所有节点的操作系统时间必须一致！不然会出现某个节点 Session 已过期而在另一节点此 Session 仍处于活动状态的现象。