TOMCAT5 集群中的SESSION复制二

版权声明：可以任意转载，转载时请务必以超链接形式标明文章原始出处和作者信息及本声明
作者:
Srini Penchikala;
原文地址:
中文地址:

关键词： Tomcat Clustering

本文是有关在TOMCAT5容器中进行SESSION复制系列的第2部分。在第一部分中，我对相对sticky的已复制的SESSION以及SESSION 复制设计所要注意的一些事项给出了个概要。我同样讨论了在一个TOMCAT集群中SESSION复制是怎样工作的，特别是当服务器自动或关闭的时候。在这个部分，我将会介绍一个样例TOMCAT集群启动的详细配置，比较不同的SESSION复制场景以及他们分别对集群性能的影响。


Tomcat 5集群中的SESSION复制 第一部分：


集群安装

为了在TOMCAT5容器中SESSION复制可用，必须完成以下步骤：
●        为了集群能够工作，你必须使用你系统上的多点传送可使用
●        为了有些使用SESSION复制，所有TOMCAT例程必须同样配置。这意味着WEB应用程序必须统一的部署在集群中的每台服务器上。这些配置同样简化了集群管理，维护和发现维修故障的任务。
●        在 server.xml未注释的Cluster 和Valve (ReplicationValve) 元素。起用server.xm中的CLUSTER元素意味着所有WEB CONTEXT的SESSION管理器将会改变。因此当运行一个集群的时候，你应该确保只有一个需要被集成WEB应用程序并且移除其他的。
●        如果服务器例程运行在同样的机器上，应该确保每个例程的tcpListenPort属性是一致的。
●        确保web.xml有distributable属性
●        所有的SESSION属性必须实现java.io.Serializable接口

范例集群安装有两个TOMCAT例程和一个负载平衡用于分配服务器间的请求。所有三个服务器都运行在一个单独的机器上，以下表格列出了集群和负载平衡上的配置参数。


编辑注解：以上Web App Directory中的值为了适应排版而换行了。在你的部署中，每个值应该是单一而完整的一行

注意：不要设置tcpListenAddress为127.0.0.1，因为127用于回环地址，在SESSION复制期间可能会出现问题。


负载平衡器安装

TOMCAT 服务器不提供失效转移能力用于当一个集群接点失效的时候重定向任何引入的请求到下一个可用的服务器上。所以我使用一个分开的负载平衡器去管理WEB请求的负载平衡。有一些流行的负载平衡器例如Apache/mod_jk, Balance, 和 Pen。我在范例集群安装中使用Pen作为负载平衡器。

Pen 是一个简单的，基于TCP协议，例如HTTP或者SMTP的负载平衡器。他允许多个服务器对外表现为一个服务器，并且自动检测关闭的服务器，在可用的服务器间分配客户断。他提供了负载平衡和失效转移能力。Pen易于安装以及配置，非常容易使用和运行在Windows和UNIX操做系统上。范例配置使用 round-robin负载平衡算法用于在集群节点间分配负载平衡

运行负载平衡器的命令如下：
pen -r -a -f -d localhost:8080 192.168.0.10:9080 192.168.0.20:10080

以下是用于启动负载平衡器的每个命令行参数的解释
-r:  使用round robin负载平衡
-a: 打印来回发送的ASCII格式的数据
-f: 保持在前台
-d: 起用DEBUG模式

想要知道更多用于启动PEN的参数细节，请访问PEN网站
图表1展示了两个集群节点，一个负载平衡器，仪器层，以及测试客户端的拓扑图


Figure 1. Cluster setup diagram

测试安装

我创建了一个叫做clusterapp的WEB应用程序来验证集群安装以及SESSION复制原理。为了测试真实的SESSION复制，我写了一个叫做 SessionReplicationClient的简单JAVA客户端用语测试从一个服务器拷贝SESSION数据到另外一个服务器的需要的时间。这个客户端使用Jakarta Commons HttpClient况架去创建和操作HTTP SESSION并且调用TOMCAT服务器上的一个SERVLET。用于测试SESSION复制的机器软硬件配置如下：
●        CPU: HP Pavilion Pentium III 800MHz
●        Memory: 512MB RAM
●        Hard disk: 40GB
●        Operating system: Windows 2000 server
●        JDK version: 1.4.2_05 (Note: JDK 1.4 or later version is required to use clustering and session replication)
●        Tomcat version: 5.0.28
●        Tools: Pen, Log4J, Eclipse, Commons HttpClient

当一个复制客户端程序运行的时候，他首先设置一个作用指令用于这样操纵SESSION（例如，添加一个新的属性到SESSION，从SESSION中移除一个已存在的属性，或则让一个SESSION失效）。然后客户端通过在Commons HttpClient框架使用HttpClient和PostMethod类调用ReplicationServlet。基于这些SESSION命令，servlet生成一个新的SEESION或者修改一个已经存在的SESSION并且转到一个WEB页面中瞻示SESSION细节。如果在管理 SESSION中有任何错误，则转到一个错误页面。我写了一个定制的SESSION监听类（ClusterAppSessionListener）用于跟踪SESSION管理的细节，例如新SESSION的创建，修改或则终止已经存在的SEESION。

图表2展现了SESSION复制流程


Figure 2. Session replication sequence diagram

服务器上的SESSION状态通过每个WEB请求的COOKIE跟踪，所以为了保持使用同样的SESSION，从客户端发出的请求URL必须一样。另外，在每次请求都创建一个新的HTTP SESSION。我使用了两种类型的，基于添加到SESSION中的属性类别的测试方法去测试复制。

第一个类别有100个轻量对象（每个1K）添加到SESSION。第2个类别中，我添加了一个单一的大对象（100K）去比较基于SESSION属性大小的SESSION复制所花费的时间

以下列出了SessionReplicationClient的测试规格：
●        客户端线程数：2
●        旋环次数：1000
●        请求延迟：1000 milliseconds
●        测试范例数：1000
●        SESSION属性：小（100个1K大小的对象）或则大（一个100K大小的对象）

使用指定参数运行测试客户端的命令如下：
java -Dlog4j.configuration=log4j.xml com.clusterapp.test.SessionReplicationClient 2 192.168.0.10 9080 1000 1000 lite

测试环境包括使用不同的SESSION管理器（SimpleTcpReplicationManager 或则 DeltaManager）和SESSION复制模式（同步，异步，池），以下表格列出了在TOMCAT集群中的一系列测试环境：



想要把复制模式从池该到同步或异步，只要在server.xml文件中的SENDER标志中修改replicationMode属性值就可以了。同样，要改变SESSION管理器的类型，只要改变Cluster元素的managerClassName属性。

以下参数用于比较反应时间和SESSION复制的效率：
●        平均反映时间（ms）
●        平均请求时间（ms）
●        集群开销时间（ms）
●        复制时间（ms）
●        比率(bytes/ms)
●        比率(bytes/request)

测试结果


delta管理器和池复制模式相结合使用对与SESSION复制效率是最好的标准。同样，保持SESSION大小较小可以比复制大SESSION快2到3倍。



复制管理器
DeltaManager 在SESSION复制方面更有效，因为他仅仅处理SESSION deltas而不是全部的SESSION数据。使用DeltaManager，与使用简单复制管理器比较，SESSION复制效率会提高30%（大 SESSION）到50%（小SESSION）。

复制模式
与其他两个选项（同步和异步）比较，池复制模式复制SESSION花费更好的时间。在一个复制时间内，池选项几乎是同意选项的 4倍快。但是在反应时间和集群开销时间方面，池和同步模式几乎一样，因为在同步模式里，集群在返回前不用等待SESSIONG完成复制

综述
基于SESSION复制测试的结果，我们得出结论：应该在任何可能时候使用DeltaManager。因为复制SESSION数据的开销是意义重大的，必须确保没有在SESSION中存储太多的数据同样，添加到SESSION中的属性大小也是影响到SESSION复制时间的另一个因素。当我运行测试在 SESSION存储大对象（100K）的时候，与在SESSION中存储小对象（1K）相比较，复制时间非常高。想要最小化SESSION复制开销最好的方法是避免调用session.setAttribute()以及把数据存储在请求对象中而不是SESSION中。这样相对更好因为当WEB请求完成的时候请求属性会被重置。同样，如果没有商业方面的原因要在服务器存储数据，我们可以以COOKIES的形式在客户端存储数据。这种方法完全避免了使用任何 SESSIOIN的需要。

一种最小化SESSION复制时间开销的方法是限制集群中到两个或则三个服务器上的服务器例程数目。这样当第一个服务器失败的时候第一个服务器上的SESSION数据已经被拷贝到第二个服务器上。为了保持网络畅通，集群可以分割成小块的组，每个组包括两个或则三个服务器例程。记住，集群中的服务器越多，SESSION复制花费的时间也越多。目前TOMCAT5不支持首要/次要复制的概念。在以后发布的版本中将会有，这样我们将可以在一个或则两个备份服务器上存储SESSION。拥有这个特性的话，TOMCAT将会为在集群环境中运行WEB服务器提供更全面的 SESSION复制方法。

在未来TOMCAT将会支持的一些属性：
●        拥有在SESSION中存在非序列化的属性的能力，集群将会忽略该属性
●        拥有复制context属性以及非序列化的相关数据的能力，例如JDBC连接池和对象CACHES。

这些特性将会使在TOMCAT集群中的SESSION复制更强壮和灵活。

I want to thank Filip Hanik for his valuable suggestions and feedback on the replication modes, session replication web application setup, and the test client sections of this article.

资源
·
·Matrix-Java开发者社区:
·onjava.com:
·Tomcat 5集群中的SESSION复制 第一部分：
·Tomcat Clustering/Session Replication Home Page:
·Tomcat Load Balancer Home Page :


Srini Penchikala is an information systems subject matter expert at Flagstar Bank.