概述
隨著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 的文章
