#概述
随着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方法通過判斷不同的會話事件進行不同的處理。
#總結
本篇部落格隻是對于tomcat叢集同步原理進行了非常粗線條的源碼分析，其中也不一定都對，而且有許多細節沒有深究，以後會繼續深入分析。