Tomcat集群Cluster实现原理剖析

org.apache.catalina.tribes.transport.ReceiverBase bind
信息: Unable to bind server socket to:/192.168.137.3:4099 throwing error.
2011-8-2 19:59:25 org.apache.catalina.tribes.transport.nio.NioReceiver start
严重: Unable to start cluster receiver
Java.NET.BindException: Cannot assign requested address
tomcat启动时上述错误，端口可以启动，但就是访问不了：
         背景：关于这个错误，其实注释掉tomcat配置中的cluster是可以的，但我使用nginx+tomcat的集群模式，所以必须使用cluster做session的共享
         首先我192.168.137.3没有4099这个端口的，怎么会说被占用不能绑定呢
于是google，了解到默认的receiver端口是分配4000-4100，那这个都到4099了，那说明这范围内已经没有可用端口分配给tomcat的receiver了
得到答案：
将tomcat中server.xml中如下配置：
<Receiver
className=”org.apache.catalina.cluster.tcp.ReplicationListener”
tcpListenAddress=”auto” //此处的auto换成本机ip或者localhost即可
tcpListenPort=”4001”
tcpSelectorTimeout=”100”
tcpThreadCount=”6”/>
         于是找到自己tomcat的配置文件修改，但是进去发现并没有这个些配置
         恕我愚钝，再次google，了解到原来我的tomcat是缩减配置，并没有相关的配置，于是自己开始加进去，添加如下配置:
<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=”228.0.0.4”
port=”45564”
frequency=”500”
dropTime=”3000”/>
<Receiver className=”org.apache.catalina.tribes.transport.nio.NioReceiver”
address=”auto”
port=”4004”
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”/>
<Deployer className=”org.apache.catalina.ha.deploy.FarmWarDeployer”
tempDir=”/tmp/war-temp/”
deployDir=”/tmp/war-deploy/”
watchDir=”/tmp/war-listen/”
watchEnabled=”false”/>
<ClusterListener className=”org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener”/>
<ClusterListener className=”org.apache.catalina.ha.session.ClusterSessionListener”/>
</Cluster>
         配置完成后即恢复正常，于是从网上搜集整理了一些说明，以备不时之需：
         对于WEB应用集群的技术实现而言，最大的难点就是如何能在集群中的多个节点之间保持数据的一致性，会话（Session）信息是这些数据中最重要的一块。要实现这一点，大体上有两种方式，一种是把所有Session数据放到一台服务器上或者数据库中，集群中的所有节点通过访问这台Session服务器来获取数据；另一种就是在集群中的所有节点间进行Session数据的同步拷贝，任何一个节点均保存了所有的Session数据。两种方式都各有优点，第一种方式简单、易于实现，但是存在着Session服务器发生故障会导致全系统不能正常工作的风险；第二种方式可靠性更高，任一节点的故障不会对整个系统对客户访问的响应产生
影响，但是技术实现上更复杂一些。常见的平台或中间件如microsoft asp.Net和IBM WAS都会提供对两种共享方式的支持，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，了解更多组播地址详情请参见http://zyycaesar.iteye.com/admin/blogs/296501），使用同一个组播地址和端口的多个节点同属一个子集群，因此通过自定义组播地址和端口就可将一个大的tomcat集群分成多个子集群。Receiver用于各个节点接收其他节点发送的数据，在默认配置下tomcat会从4000-4100间依次选取一个可用的端口进行接收，自定义配置时，如果多个tomcat节点在一台物理服务器上注意要使用不同的端口。Sender用于向其他节点发送数据，具体实现通过Transport配置，PooledParallelSender是从tcp连接池中获取连接，可以实现并行发送，即集群中的多个节点可以同时向其他所有节点发送数据而互不影响。Interceptor有点类似下面将要解释的Valve，起到一个阀门的作用，在数据到达目的节点前进行检测或其他操作，如TcpFailureDetector用于检测在数据的传输过程中是否发生了tcp错误。关于Channel的编程模型，请参见http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/catalina/tribes/Channel.html。

         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节点最好采用相同的配置。