概述
随着C/S架构中，客户端对服务器的访问量及访问次数逐渐增多，单个服务器已经不能够满足客户端的请求了。于是现在大多数服务器都做成了集群的形式。而服务器集群会有一个很大问题，就是同步问题。比如，现在我对一个有四台计算机的集群进行访问，这时假设根据负载均衡分配到了Node1，如果我在Node1上创建了一个session对象，这时，在服务器响应客户端之前，一定是要先将创建session对象的信息同步到其它节点上的。这样，我们在客户端第二次发起请求时，假设分到了Node2，我们也可以直接获取session信息。照常进行会话。如果我们在某个服务器上删除了会话，那么同样，在响应之前也会同步其它节点也删除会话。如图：
tomcat集群同步的大致过程就是如上所述。那么更深一点的原理是什么呢，接下来我一点一点的深入探索。
同步组件
在上述无论是发送还是接收信息的过程中，使用到的组件主要有三个：Manager,Cluster,tribes。简单来讲，Manager的作用是将操作的信息记录下来，然后序列化后交给Cluster，接着Cluster是依赖于tribes将信息发送出去的。其余节点收到信息后，按照相反的流程一步步传到Manager，经过反序列化之后使该节点同步传递过来的操作信息。如图，假设我们访问的是中间的节点，该节点将信息同步出去。信息是以Cluster Message对象发送的。
同步方式
关于集群的具体同步机制，tomcat共提供了两种。一种是集群增量会话管理器，另一种是集群备份会话管理器。
集群增量会话管理器
这是一种全节点复制模式，全节点复制指的是集群中一个节点发生改变后会同步到其余全部节点。那么非全节点复制，顾名思义，指的是集群中一个节点发生改变后，只同步到其余一个或部分节点。
除了这一特点，集群增量会话管理器还具有只同步会话增量的特点，增量是以一个完整请求为周期，也就是说会在一个请求被响应之前同步到其余节点上。
集群备份会话管理器
全节点复制模式存在的一个很大的问题就是用于备份的网络流量会随着节点数的增加而急速增加，这也就是无法构建较大规模集群的原因。为了解决这个问题，tomcat提出了集群备份会话管理器。每个会话只有一个备份。这样就可构建大规模的集群。
源码分析
我这里以集群增量会话管理器为例对tomcat7.0.78中的源码进行分析。
DeltaRequest
DeltaRequest对象记录了请求执行过程中的一系列操作。该对象最终会被序列化，然后传输到其余节点后再被反序列化为该对象，从而进行本地节点对会话操作的同步。
DeltaRequest对象是记录对会话操作的，那么会话事件（如创建会话，销毁会话，更改会话属性）是在哪里定义的呢？而针对不同会话事件的不同操作是如何定义的呢？
SessionMessageImpl
tomcat中的SessionMessageImpl类定义了不同的会话事件及操作方法。此类与其它类之间的继承（与其它接口的实现）关系如图：
有了这样的关系，我们就知道此类继承（实现）了许多属性和方法，比如它实现了SessionMessage接口中对会话事件的定义：
它还继承了ClusterMessage类，Serializable类，分别用于对集群的操作和序列化。
ChannelListener
当信息被序列化发送出去后，节点通过信道监听信息。实现的接口如下：
这个接口由Cluster具体实现，在tribes接收到message后。首先会调用accept方法判断是否需要接收此信息，如果返回值为True，那么就调用messageReceived方法来接收message。接着它会回调DeltaManager类中的messageDataReceived方法来进行处理。
这个方法对各种不同的会话事件进行处理。其中的messageReceived方法通过判断不同的会话事件进行不同的处理。
閱讀更多 有理想的代碼dog 的文章
