链接 用户手册 参考 Apache Tomcat 开发 | | 快速入门 |
要在Tomcat 5.5容器里进行session复制，必须完成下列步骤：
- 你的所有会话属性值必须实现
java.io.Serializable
- 把server.xml文件里的群集(
Cluster)元素的注释取消(Uncomment)
- 把server.xml文件里的
Valve(ReplicationValve)元素注释取消(Uncomment)
- 如果有多个Tomcat实例在一台机器上运行，确保每个实例的
tcpListenPort属性值是不冲突的。
- 确定
web.xml 中含有 <distributable/> 元素，
或者设置 <Context distributable="true" />
- 确定设置好Engine元素的 jvmRoute 的属性值：
<Engine name="Catalina" jvmRoute="node01" >
- 确定所有节点拥有相同的时间， 并且通过网络时间服务(NTP)同步操作系统的时间！
- 确定负载均衡器已经配置为黏性会话模式.
负载均衡可以有很多种方式实现，请参考负载均衡章节。
注意：记住你的会话状态是被一个cookie跟踪的，所以你的URL从外面看必须是相同的，否则一个新的session就会被产生。
注意：集群支持目前需要JDK 1.4或其后版本。
|
| 它是怎样工作的 |
为了便于理解集群是怎样工作的,我们将用一系列的场景来描述.
在这个场景中，我们只计划使用两个tomcat 实例 TomcatA 和 TomcatB.
我们将覆盖下面连续的事件:
TomcatA 启动TomcatB 启动 (等待TomcatA 启动完成)TomcatA 接受一个请求，session S1 被产生。TomcatA 崩溃停止TomcatB 接受一个session S1的请求TomcatA 启动TomcatA 接受一个请求，session ( S1 )失效。TomcatB 接受一个新的session ( S2 )的请求。TomcatA 因为没有活动session S2过期失效。
好了, 现在我们有了一个很好的顺序,我们将告诉你在session复制代码里发生的所有事情
TomcatA 启动
Tomcat 标准方式启动. 当 Host 对象被创建之后, 一个 cluster 对象与它关联.
当上下文被解析完, 如果 web.xml中有distributable元素，
Tomcat 通过 Cluster class (in this case SimpleTcpCluster)为支持复制的上下文创建一个管理器.
因此通过设置web.xml中的distributable来启用集群。
Tomcat 将为上下文创建 DeltaManager莱取代 StandardManager.
cluster class 将启动 a membership service (multicast) 和 a replication service (tcp unicast).
More on the architecture further down in this document.
TomcatB 启动当TomcatB启动时，除了一个例外以外，它按照TomcatA一样的顺序启动。群集被启用，并将建立一组会员(TomcatA,TomcatB)。TomcatB现在将要request已经存在于群集里的服务器的会话状态，在这里这个服务器是TomcatA。TomcatA回应TomcatB的请求，并且在TomcatB开始为HTTP requests监听之前，这个状态已经由TomcatA传递给TomcatB了。在TomcatA不回应的情况下，TomcatB在60秒后中断，并发出一个日志记录。对于每个已经分布在web.xml里的web应用程序，会话状态会被转移。注意：要有效地使用会话复制，你的所有tomcat实例要配置成一样的。
TomcatA 接受一个请求，session S1 被产生。
TomcatA对待传递来的请求与对待没有会话复制一样。当请求完成以后，活动就开始了，ReplicationValve在回应被返回到用户那里之前会截断这个请求。在这时，它发现会话被修改过，它就用TCP把这个会话复制给TomcatB。一旦这个分段的数据被递交给操作系统TCP logic，请求就通过valve pipeline返回给用户。对于每个请求，整个会话都被复制，这允许在不调用setAttribute 或 removeAttribute情况下，在会话中修改属性的代码被复制。配置参数useDirtyFlag可以被用来优化会话复制的次数。
TomcatA 崩溃停止
当TomcatA崩溃时，TomcatB会收到通知说TomcatA已经退出群集。TomcatB把TomcatA从它的会员列单中删除掉，TomcatB里有任何更改也不会再通知TomcatA。装载均衡器会把对TomcatA的请求引向TomcatB以及所有当前活动会话。
TomcatB 接受一个session S1的请求TomcatB像处理其他任何请求一样处理这个请求。
TomcatA 启动
TomcatA启动时，在它接受新的请求以及让它自己可被使用之前，它要按照上面 1) 2)中所描述的顺序进行启动。它会加入群集，与TomcatB联系，了解所有会话的当前状态。一旦它接受到会话状态，它就完成装载并打开它的HTTP/mod_jk ports。所以在TomcatA接受到来自TomcatB的会话状态之前，不会对它发出请求。
TomcatA 接受一个请求，session ( S1 )失效。
失效的呼叫被拦截，这个会话就加入到失效的会话行列。在这个请求完成以后，它向TomcatB发出一个"expire"信息，TomcatB也把这个会话变为失效。
TomcatB 接受一个新的session ( S2 )的请求。
与步骤3)情形一样。
TomcatA 因为没有活动session S2过期失效。就如一个会话由用户让它无效一样，invalidate呼叫被拦截到，这个会话就加入失效的会话行列。这一点上，除非另一个请求通过系统来检查失效行列，会话失效不会在其他地方重复。
Phuuuhh! :)
Membership Clustering membership可以通过使用非常简单的multicast pings被建立。每个Tomcat实例定期会发出multicast ping，在ping message里，这个实例会散布它的IP 及 TCP 监听端口以用于复制。如果一个实例在所给的时间范围内还没有收到这样的ping，这个会员就被认为是不存在了。很简单，也很有效。当然，你需要在你的系统上让multicasting可被使用。
TCP Replication，在收到一个multicast ping以后，会员就被添加到群集里。在下一个复制请求时，发出请求的实例将使用host和port信息来建立一个TCP socket。通过使用这个socket，它把分段的数据发送过去。我选择TCP sockets 的原因是它具备有流量控制，并确保发送到位。因此，我知道，当我发送数据时，这个数据就会被送到。
Distributed locking and pages using frames： Tomcat 并没有让会话实例在群集之间保持一致。这个逻辑的实现需要太大空间，也会带来很多问题。如果你的客户使用多个请求同时访问同一个会话，那么最后一个请求会覆盖群集里的其它会话。
|
| Cluster Configuration |
群集配置在样品server.xml 文件里有描述。需要指出的是以mcastXXX开头的是关于会员成分multicast ping的属性，以tcpXXX开头的是关于TCP replication的属性。
会员成分是通过在相同的multicast IP 和 port上的所有tomcat实例建立的。TCP listen port是从其他会员那里来的会话复制在这它里被接收到的端口。
复制阀被用来发现请求什么时候被完成，并启动复制。
One of the most important performance considerations is the synchronous (pooled or not pooled) versus asynchronous replication
mode. In a synchronous replication mode the request doesn't return until the replicated session has been
sent over the wire and reinstantiated on all the other cluster nodes.
There are two settings for synchronous replication. Pooled or not pooled.
Not pooled (ie replicationMode="fastasnycqueue" or "synchronous") means that all the replication request are sent over a single
socket.
Using synchronous mode can potentially becomes a bottleneck when a lot of messages generated,
You can overcome this bottleneck by setting replicationMode="pooled" but then you worker threads blocks with replication .
What is recommended here is to increase the number of threads that handle
incoming replication request. This is the tcpThreadCount property in the cluster
section of server.xml. The pooled setting means that we are using multiple sockets, hence increases the performance.
Asynchronous replication, should be used if you have sticky sessions until fail over, then
your replicated data is not time crucial, but the request time is, at this time leave the tcpThreadCount to
be number-of-nodes-1.
During async replication, the request is returned before the data has been replicated. async replication yields shorter
request times, and synchronous replication guarantees the session to be replicated before the request returns.
The parameter "replicationMode" has four different settings: "pooled", "synchronous", "asynchronous" and "fastasyncqueue"
|
| 通过 JMX 监控集群 |
Monitoring is a very important question when you use a cluster. Some of the cluster objects are JMX MBeans
Add the following parameter to your startup script with Java 5:
 | | | |
set CATALINA_OPTS=\
-Dcom.sun.management.jmxremote \
-Dcom.sun.management.jmxremote.port=%my.jmx.port% \
-Dcom.sun.management.jmxremote.ssl=false \
-Dcom.sun.management.jmxremote.authenticate=false
| | | | |
在 JDK 1.4中启用JMX:
- 安装 compat 包
- 安装 mx4j-tools.jar 到 common/lib (使用与tomcat发布版相同的mx4j版本)
- Configure a MX4J JMX HTTP Adaptor at your AJP Connector
| | | |
<Connector port="${AJP.PORT}"
handler.list="mx"
mx.enabled="true"
mx.httpHost="${JMX.HOST}"
mx.httpPort="${JMX.PORT}"
protocol="AJP/1.3" />
| | | | |
- 启动Tomcat,然后再浏览器中访问 http://${JMX.HOST}:${JMX.PORT}
- 通过连接参数
mx.authMode="basic" mx.authUser="tomcat" mx.authPassword="strange"可以控制访问权限!
集群 Mbeans 列表
| name(名称) |
描述 |
MBean ObjectName - Engine |
MBean ObjectName - Host |
| 集群 |
The complete cluster element |
type=Cluster |
type=Cluster,host=${HOST} |
| ClusterSender |
Configuration and stats of the sender infrastructure |
type=ClusterSender |
type=ClusterSender,host=${HOST} |
| ClusterReceiver |
Configuration and stats of the recevier infrastructure |
type=ClusterReceiver |
type=ClusterReceiver,host=${HOST} |
| ClusterMembership |
Configuration and stats of the membership infrastructure |
type=ClusterMembership |
type=ClusterMembership,host=${HOST} |
| IDataSender |
For every cluster member it exist a sender mbeans.
It exists speziall MBeans to all replication modes |
type=IDataSender,
senderAddress=${MEMBER.SENDER.IP},
senderPort=${MEMBER.SENDER.PORT} |
type=IDataSender,host=${HOST},
senderAddress=${MEMBER.SENDER.IP},
senderPort=${MEMBER.SENDER.PORT} |
| DeltaManager |
This manager control the sessions and handle session replication |
type=Manager,path=${APP.CONTEXT.PATH}, host=${HOST} |
type=Manager,path=${APP.CONTEXT.PATH}, host=${HOST} |
| ReplicationValve |
This valve control the replication to the backup nodes |
type=Valve,name=ReplicationValve |
type=Valve,name=ReplicationValve,host=${HOST} |
| JvmRouteBinderValve |
This is a cluster fallback valve to change the Session ID to the current tomcat jvmroute. |
type=Valve,name=JvmRouteBinderValve,
path=${APP.CONTEXT.PATH} |
type=Valve,name=JvmRouteBinderValve,host=${HOST},
path=${APP.CONTEXT.PATH} |
|
|
