本文共 15040 字,大约阅读时间需要 50 分钟。
前言:
tomcat集群中的session管理,主要有两种方式:
1).粘性session
表示从同一窗口发来的请求都将有集群中的同一个tomcat进行处理。配置方式是在上面workers.properties文件中
粘性session的好处在不会在不同的tomcat上来回跳动处理请求,但是坏处是如果处理该session的tomcat崩溃,那么之后的请求将由其他tomcat处理,原有session失效而重新新建一个新的session,这样如果继续从session取值,会抛出nullpointer的访问异常。
2).session复制
session 复制是指tomcat彼此之间通过组播方式将session发到各个tomcat实例上,
好处是如果其中一个访问出错,则另外tomcat仍然具有有效的session内容,从而能正常接管其session。
坏处是当tomcat实例很多,或者用户在session中有大量操作时,组播发送的信息量十分惊 人。session复制配置则是在发布的web应用程序中的web.xml中添加
此外,session复制所需的JDK必须是JDK 5.0及其以上版本。
==============================================================
第一部分
原文地址:http://www.onHashMap 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 银行工作的信息系统主题专家。 第二部分 集群安装 为了在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集群中的一系列测试环境: 您正在看的JAVA教程是:Tomcat 5集群中的SESSION复制二。 想要把复制模式从池该到同步或异步,只要在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.
转载地址:http://jwqzb.baihongyu.com/