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

Tomcat 5中的SESSION复制

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

    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 银行工作的信息系统主题专家。