TOMCAT5 集群中的SESSION復制-第2部分

作者:
Srini Penchikala;Sunny983
原文地址:http://www.onjava.com/pub/a/onjava/2004/12/15/replication2.html
中文地址:
http://www.matrix.org.cn/resource/article/43/43865_Tomcat_Clustering.html
關鍵詞： Tomcat Clustering

本文是有關在TOMCAT5容器中進行SESSION復制系列的第2部分。在第一部分中，我對相對sticky的已復制的SESSION以及SESSION復制設計所要注意的一些事項給出了個概要。我同樣討論了在一個TOMCAT集群中SESSION復制是怎樣工作的，特別是當服務器自動或關閉的時候。在這個部分，我將會介紹一個樣例TOMCAT集群啟動的詳細配置，比較不同的SESSION復制場景以及他們分別對集群性能的影響。


Tomcat 5集群中的SESSION復制 第一部分：http://www.matrix.org.cn/resource/article/43/43865_Tomcat_Clustering.html


集群安裝

為了在TOMCAT5容器中SESSION復制可用，必須完成以下步驟：
● 為了集群能夠工作，你必須使用你系統上的多點傳送可使用
● 為了有些使用SESSION復制，所有TOMCAT例程必須同樣配置。這意味著WEB應用程序必須統一的部署在集群中的每臺服務器上。這些配置同樣簡化了集群管理，維護和發現維修故障的任務。
● 在server.xml未注釋的Cluster 和Valve (ReplicationValve) 元素。起用server.xm中的CLUSTER元素意味著所有WEB CONTEXT的SESSION管理器將會改變。因此 當運行一個集群的時候，你應該確保只有一個需要被集成WEB應用程序并且移除其他的。
● 如果服務器例程運行在同樣的機器上，應該確保每個例程的tcpListenPort屬性是一致的。
● 確保web.xml有distributable屬性
● 所有的SESSION屬性必須實現java.io.Serializable接口

范例集群安裝有兩個TOMCAT例程和一個負載平衡用于分配服務器間的請求。所有三個服務器都運行在一個單獨的機器上，以下表格列出了集群和負載平衡上的配置參數。




編輯注解：以上Web App Directory中的值為了適應排版而換行了。在你的部署中，每個值應該是單一而完整的一行

注意：不要設置tcpListenAddress為127.0.0.1，因為127用于回環地址，在SESSION復制期間可能會出現問題。


負載平衡器安裝

TOMCAT服務器不提供失效轉移能力用于當一個集群接點失效的時候重定向任何引入的請求到下一個可用的服務器上。所以我使用一個分開的負載平衡器去管理WEB請求的負載平衡。有一些流行的負載平衡器例如Apache/mod_jk, Balance, 和 Pen。我在范例集群安裝中使用Pen作為負載平衡器。

Pen是一個簡單的，基于TCP協議，例如HTTP或者SMTP的負載平衡器。他允許多個服務器對外表現為一個服務器，并且自動檢測關閉的服務器，在可用的服務器間分配客戶斷。他提供了負載平衡和失效轉移能力。Pen易于安裝以及配置，非常容易使用和運行在Windows和UNIX操做系統上。范例配置使用round-robin負載平衡算法用于在集群節點間分配負載平衡

運行負載平衡器的命令如下：
pen -r -a -f -d localhost:8080 192.168.0.10:9080 192.168.0.20:10080

以下是用于啟動負載平衡器的每個命令行參數的解釋
-r: 使用round robin負載平衡
-a: 打印來回發送的ASCII格式的數據
-f: 保持在前臺
-d: 起用DEBUG模式

想要知道更多用于啟動PEN的參數細節，請訪問PEN網站
圖表1展示了兩個集群節點，一個負載平衡器，儀器層，以及測試客戶端的拓撲圖




Figure 1. Cluster setup diagram

測試安裝

我創建了一個叫做clusterapp的WEB應用程序來驗證集群安裝以及SESSION復制原理。為了測試真實的SESSION復制，我寫了一個叫做SessionReplicationClient的簡單JAVA客戶端用語測試從一個服務器拷貝SESSION數據到另外一個服務器的需要的時間。這個客戶端使用Jakarta Commons HttpClient況架去創建和操作HTTP SESSION并且調用TOMCAT服務器上的一個SERVLET。用于測試SESSION復制的機器軟硬件配置如下：
● CPU: HP Pavilion Pentium III 800MHz
● Memory: 512MB RAM
● Hard disk: 40GB
● Operating system: Windows 2000 server
● JDK version: 1.4.2_05 (Note: JDK 1.4 or later version is required to use clustering and session replication)
● Tomcat version: 5.0.28
● Tools: Pen, Log4J, Eclipse, Commons HttpClient

當一個復制客戶端程序運行的時候，他首先設置一個作用指令用于這樣操縱SESSION（例如，添加一個新的屬性到SESSION，從SESSION中移除一個已存在的屬性，或則讓一個SESSION失效）。然后客戶端通過在Commons HttpClient框架使用HttpClient和PostMethod類調用ReplicationServlet。基于這些SESSION命令，servlet生成一個新的SEESION或者修改一個已經存在的SESSION并且轉到一個WEB頁面中瞻示SESSION細節。如果在管理SESSION中有任何錯誤，則轉到一個錯誤頁面。我寫了一個定制的SESSION監聽類（ClusterAppSessionListener）用于跟蹤SESSION管理的細節，例如新SESSION的創建，修改或則終止已經存在的SEESION。

圖表2展現了SESSION復制流程




Figure 2. Session replication sequence diagram

服務器上的SESSION狀態通過每個WEB請求的COOKIE跟蹤，所以為了保持使用同樣的SESSION，從客戶端發出的請求URL必須一樣。另外，在每次請求都創建一個新的HTTP SESSION。我使用了兩種類型的，基于添加到SESSION中的屬性類別的測試方法去測試復制。

第一個類別有100個輕量對象（每個1K）添加到SESSION。第2個類別中，我添加了一個單一的大對象（100K）去比較基于SESSION屬性大小的SESSION復制所花費的時間

以下列出了SessionReplicationClient的測試規格：
● 客戶端線程數：2
● 旋環次數：1000
● 請求延遲：1000 milliseconds
● 測試范例數：1000
● SESSION屬性：小（100個1K大小的對象）或則大（一個100K大小的對象）

使用指定參數運行測試客戶端的命令如下：
java -Dlog4j.configuration=log4j.xml com.clusterapp.test.SessionReplicationClient 2 192.168.0.10 9080 1000 1000 lite

測試環境包括使用不同的SESSION管理器（SimpleTcpReplicationManager 或則 DeltaManager）和SESSION復制模式（同步，異步，池），以下表格列出了在TOMCAT集群中的一系列測試環境：





想要把復制模式從池該到同步或異步，只要在server.xml文件中的SENDER標志中修改replicationMode屬性值就可以了。同樣，要改變SESSION管理器的類型，只要改變Cluster元素的managerClassName屬性。

以下參數用于比較反應時間和SESSION復制的效率：
● 平均反映時間（ms）
● 平均請求時間（ms）
● 集群開銷時間（ms）
● 復制時間（ms）
● 比率(bytes/ms)
● 比率(bytes/request)

測試結果


delta管理器和池復制模式相結合使用對與SESSION復制效率是最好的標準。同樣，保持SESSION大小較小可以比復制大SESSION快2到3倍。





復制管理器
DeltaManager在SESSION復制方面更有效，因為他僅僅處理SESSION deltas而不是全部的SESSION數據。使用DeltaManager，與使用簡單復制管理器比較，SESSION復制效率會提高30%（大SESSION）到50%（小SESSION）。

復制模式
與其他兩個選項（同步和異步）比較，池復制模式復制SESSION花費更好的時間。在一個復制時間內，池選項幾乎是同意選項的 4倍快。但是在反應時間和集群開銷時間方面，池和同步模式幾乎一樣，因為在同步模式里，集群在返回前不用等待SESSIONG完成復制

綜述
基于SESSION復制測試的結果，我們得出結論：應該在任何可能時候使用DeltaManager。因為復制SESSION數據的開銷是意義重大的，必須確保沒有在SESSION中存儲太多的數據同樣，添加到SESSION中的屬性大小也是影響到SESSION復制時間的另一個因素。當我運行測試在SESSION存儲大對象（100K）的時候，與在SESSION中存儲小對象（1K）相比較，復制時間非常高。想要最小化SESSION復制開銷最好的方法是避免調用session.setAttribute()以及把數據存儲在請求對象中而不是SESSION中。這樣相對更好因為當WEB請求完成的時候請求屬性會被重置。同樣，如果沒有商業方面的原因要在服務器存儲數據，我們可以以COOKIES的形式在客戶端存儲數據。這種方法完全避免了使用任何SESSIOIN的需要。

一種最小化SESSION復制時間開銷的方法是限制集群中到兩個或則三個服務器上的服務器例程數目。這樣當第一個服務器失敗的時候第一個服務器上的SESSION數據已經被拷貝到第二個服務器上。為了保持網絡暢通，集群可以分割成小塊的組，每個組包括兩個或則三個服務器例程。記住，集群中的服務器越多，SESSION復制花費的時間也越多。目前TOMCAT5不支持首要/次要復制的概念。在以后發布的版本中將會有，這樣我們將可以在一個或則兩個備份服務器上存儲SESSION。擁有這個特性的話，TOMCAT將會為在集群環境中運行WEB服務器提供更全面的SESSION復制方法。

在未來TOMCAT將會支持的一些屬性：
● 擁有在SESSION中存在非序列化的屬性的能力，集群將會忽略該屬性
● 擁有復制context屬性以及非序列化的相關數據的能力，例如JDBC連接池和對象CACHES。

這些特性將會使在TOMCAT集群中的SESSION復制更強壯和靈活。[@more@]