#概述
隨著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集群同步原理進行了非常粗線條的源碼分析，其中也不一定都對，而且有許多細節沒有深究，以后會繼續深入分析。

總結

以上是生活随笔為你收集整理的Tomcat集群同步原理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。