Tomcat 5集群中的SESSION复制（2）

Tomcat 5中的SESSION复制

在版本5之前，TOMCAT服务器只支持sticky sessions （使用mod_jk模块进行负载平衡）。如果我们需要SESSION复制，必须依靠第3方软件例如Java Groups 去实现。

Tomcat 5服务器带有SESSION复制功能。和集群特征类似，只要修改 server.xml 注册文件就能实现SESSION复制。

Martin Fowler 在他的书《 Enterprise Patterns》中谈到三个SESSION状态持久性模式，这些模式包括：

1.客户端SESSION状态：在客户端存储SESSION状态

2.服务端SESSION状态：在一个序列化的FORM中保持SESSION状态到一个服务器系统上。

3.数据库SESSION状态：当在数据库中提交数据的时候存储SESSION数据。

TOMCAT支持以下三种SESSION持久性类型：

1.内存复制：在JVM内存中复制SESSION状态，使用TOMCAT 5安装带的SimpleTcpCluster 和 SimpleTcpClusterManager 类。这些类在包org.apache.catalina.cluster中，是server/lib/catalina-cluster.jar的一部 分。

2.数据库持久性：在这种类型中，SESSION状态保存在一个关系数据库中，服务器使用JDBCManager类从数据库中获取SESSION信息。这 个类在包org.apache.catalina.session.JDBCStore中，是catalina.jar的一部分。

3.基于文件的持久性：这里使用类PersistenceManager把SESSION状态保存到一个文件系统。这个类在包org.apache.catalina.session.FileStore中，是catalina.jar的一部分。

TOMCAT集群元素以及SESSION复制这章简要介绍一下组成TOMCAT集群的元素以及SESSION复制。

集群：

这个是集群中的主要元素， SimpleTcpCluster类代表这个元素。他使用在server.xml中指定的管理类为所有可分配的web contexts生成ClusterManager.

集群管理器

这个类关注跨越集群中所有节点间的SESSION数据复制。所有在web.xml文件中指定了distributable标记的WEB应用程序都会有 SESSION复制。集群管理器作为集群元素的managerClassName属性在server.xml中指定。集群管理器的代码主要被设计用来分离 集群中的元素。我们所要做的就是写一个SESSION管理器类去实现ClusterManager接口。这样能让我们灵活的使用客户集群管理器而不会影响 到集群中的其他元素。这里有两个复制算法。SimpleTcpReplicationManager每次复制全部的SESSION，而 DeltaManager只复制SESSION增量。

最简单的复制管理器在每次HTTP请求都复制所有的SESSION.在SESSION较小的时候这样是很有用的，我们可以只用以下代码：

HashMap map = session.getAttribute（"map"）；map.put（"data"，"data"）；

这里，我们不需要特别调用session.setAttribute（） 或者 removeAttribute方法去复制SESSION变化。对于每次HTTP请求，在SESSION中的所有属性都被复制。可以使用一个叫做 useDirtyFlag的属性去最优化SESSION被复制的次数。如果这个标记被设为真，我们必须调用setAttribute（）方法去获取被复制 的SESSION变化。如果被设为假，每次请求后SESSION都被复制。

SimpleTcpReplicationManager生成ReplicatedSession执行SESSION复制工作。

提供增量管理器仅仅是为了性能的考虑。它在每次请求的时候都做一次复制。同时他也调用监听器，所以如果我们调用 session.setAttribute（），那么在其他服务器上的监听器就会被调用。DeltaManager生成DeltaSession执行 SESSION复制。

成员成员的建立通过由TOMCAT例程在同样的多点传送IP和端口发送广播消息。广播的消息包括服务器的IP地址和TCP监听端口（默认IP地址为228.0.0.4）。

如果在给定的时间框架内一个例程没有接收到消息（由集群配置中的mcastDropTime参数指定），成员被认为死亡。这个元素由McastService类表示。

由mcastXXX开始的属性用于成员资格多点传送PING.以下表格列出了用于IP多点传送服务器通讯的属性。

发送端

这个元素由ReplicationTransmitter类代表。当多点传送广播消息被接收到，成员被添加到机群。在下次复制请求前，发送例程将使用主机 和端口信息建立一个TCP SOCKET.使用这些SOCKET发送序列化的数据。在TOMCAT 5中有3种不同的方法操纵SESSION复制：异步，同步，池复制模式。以下部分解释了这些模式怎样工作，以及他们将被使用在什么情况下。

●异步：在这种复制模式中，每个集群节点都有一个单线程扮演SESSION数据传送器。这里，请求线程会把复制请求发送到一个队列，然后返回给客户端。在 失效无缝转移前，如果我们拥有sticky sessions，就应该使用异步复制。这里复制时间不是至关重要的，但是请求时间却是。在异步复制期间，请求在数据被复制完之前就返回了。这种复制模式 缩短了请求时间。当每个请求被分的更开这种模式是很有用的。（例如，在WEB请求间有更长的延迟）。同样，如果我们不关心SESSION是否完成复制这个 也很有用，当SESSION很较小时， SESSION复制时间也更短。

●同步：在这种模式中，一个单线程执行了HTTP请求和数据复制。集群中所有节点都接收到SESSION数据后线程才返回。同步意味被被复制的数据通过一 个单SOCKET发送。由于使用一个单线程，同步模式可能会是簇性能的一个潜在的瓶颈。这种复制模式保证了在请求返回前SESSION 已经被复制。

●池：TOMCAT5 在使用池复制模式进行SESSION复制的方法上提供了很大的改进。

池模式基本上是同步模式的一个扩展版本。他基于的一个原则是：划分服务到多例程，每个例程处理不同的SESSION数据片段。同时对接收服务器开放多 SOCKET进行发送SESSION信息。这种方法比通过单SOCKET发送所有东西更快。因此，使用一个SOCKET池同步复制SESSION.直到所 有SESSION数据都复制完请求才返回。为了有效使用这种模式要增加TCP线程。由于使用多SOCKET，池模式使得集群性能的逐步提高以及更好的可测 性。同样这种模式也是最安全 的配置，因为它有足够数量的SOCKET在理想的时间内发送所有的SESSION数据到其他节点上。而使用单SOCKET，SESSION数据在通过集群时可能丢失或者只是部分传输。

接收端

这个集群元素由类ReplicationListener表示。在集群配置中以tcpXXX开始的属性用于TCP SESSION复制。以下表格列出了用于配置服务器复制中基于SOCEKT服务器通讯的属性。

复制值

复制值用于判断哪些HTTP请求需要被复制。由于我们不经常复制静态内容（例如HTML和javascript， stylesheets，图像文件），我们可以使用复制值元素过滤掉静态内容。这个值可以用于找出什么时候请求已完成以及初始化复制。

部署器

部署器元素可以用于部署集群范围的应用程序。通常，部署只部署/解除部署簇内的工作成员。所以在损坏的节点在启动时没有WARS的复制。当 watchEnabled="true"时配置器为WAR文件监视一个目录（watchDir）。当添加一个新的WAR文件时，WAR被部署到本地例程， 然后被部署到集群中的其他例程。当一个WAR文件从watchDir删除，这个WAR被从本地和集群范围内解除部署。

所有在TOMCAT集群结构中的元素以及他们的层次关系都在列在图1中

图 1. Tomcat 集群等级结构图。单击看原图。

TOMCAT中SESSION复制是怎么工作的

以下部分简要解释当TOMCAT服务器启动或则关闭时集群节点怎样分享SESSION信息，详细信息可参考Tomcat 5 Clustering文挡。

TC-01：集群中第一个节点TC-02：集群中第2个节点

●服务器启动：TC-01使用标准服务器启动队列启动。当主机对象被创建，即有一个集群对象和它相关联。当contexts被解析，如果 distributable已经在web.xml中指定，那么TOMCAT为WEB CONTEXT创建SESSION管理器（SimpleTcpReplicationManager 取代StandardManager）。集群将会启动一个成员服务（成员的一个例程）和一个复制服务。

当TC-02启动，他也遵循第一个成员（TC-01）同样的队列但是有一个不同。集群被启动并且创建一个成员关系（TC-01，TC-02）。TC-02 将向TC-01请求SESSION状态。TC-01回应该请求，在TC-2开始监听HTTP请求前，TC-01发送状态给TC-02.如果TC-01不回 应，TC-02将在60秒后进入中止状态并且发布一个日志入口。SESSIONG 状态发送给所有在web.xml中指定了distributable的WEB应用程序。

●创建SESSION：当TC-01接收到请求，一个SESSION（S1）被创建，处理进入TC-01的请求和没有SESSION复制时是一样的。当请 求完成时会有以下事件：ReplicationValve将会在回应返回给用户前截取请求。这里，会发现SESSION已经被改变，使用TCP复制 SESSION到TC-02.●服务器储运损耗/关闭：当在集群中的一台服务器失败，维护损坏或者系统升级，其他节点会受到第一个节点已经脱离集群的通 知。TC-02从他的成员资格列删除TC-01，并且TC-02在也不会收到有关TC-01任何变动的通知。负载平衡将会移至TC-02，所有的 SESSION由TC-02控制。

当TC-01开始恢复，他再次遵循在服务器开始阶段描述的启动队列。加入到簇中并且以所有SESSIONG的当前状态和TC-02通讯。一旦接收 到 SESSIONG状态，也就完成了加载然后打开它的HTTP/ mod_jk端口。所以，要等到从TC-2接受到SESSION状态TC-01才能发送请求。

●SESSION终止：如果在第一个节点的一个SESSION已经无效或则由于过期终止，无效请求将被截取，SESSION会被同其他无效SESSION 放在一个队列中。当请求完成，服务器发送SESSIONG终止消息给TC-02而不是发送已经改变的SESSION，TC-02同样也会把该 SESSION置无效。我们可以从服务器控制台看到SESSIONG无效的消息。无效SESSION在集群中将不会被复制，直到其他请求传出系统并且检查 无效队列。

结束语

在这篇文章中，我谈了有关在集群环境中的SESSION复制，以及编写要求在内存内SESSIONG复制的J2EE应用程序时的一些设计注意事项。我同时 也讨论了在TOMCAT 5容器中被指定来进行SESSIONG复制的簇元素。在这个系列的第2部分，我们将会看看怎样使用不同的SESSIONG 管理器和复制模式在TOMCAT集群中配置SESSIONG复制。

Srini Penchikala 是一个在Flagstar 银行工作的信息系统主题专家。