Tomcat 5集群中的SESSION復制 第一部分作者： Srini Penchikala 11/24/2004翻譯：Sunny983版權聲明：可以任意轉載，轉載時(shí)請務(wù)必以超鏈接形式標明文章原始出處和作者信息及本聲明
作者:
Srini Penchikala;
Sunny983原文地址:
http://www.onjava.com/pub/a/onjava/2004/11/24/replication1.html中文地址:
http://www.matrix.org.cn/resource/article/43/43865_Tomcat_Clustering.html關(guān)鍵詞： Tomcat Clustering
Tomcat 5服務(wù)器為集群和SESSION復制提供了集成的支持。本系列的第一篇文章將為大家提供SESSION持久性以及TOMCAT集群中SESSION復制的內在工作機制一個(gè)概要認識。我將會(huì )討論SESSION復制在TOMCAT5中是怎樣進(jìn)行的以及跨越多集群節點(diǎn)的SESSION持久性的復制機制。在第2部分，我會(huì )詳細討論一個(gè)帶有SESSION復制功能的TOMCAT集群的安裝例子，并且比較不同的復制情形。
集群傳統獨立服務(wù)器（非集群的）不提供任何失效無(wú)縫轉移以及負載平衡能力。當服務(wù)器失敗的時(shí)候，就無(wú)法獲取整個(gè)網(wǎng)站的內容，除非服務(wù)器被重新喚起。由于服務(wù)器失效，任何存儲在服務(wù)器內存中的SESSION都會(huì )丟失，用戶(hù)必須重新登陸并且輸入所有由于服務(wù)器失效丟失的數據。
不同的是，作為集群一部分的服務(wù)器則提供了可測性以及失效無(wú)縫轉移能力。一個(gè)集群就是一組同步運行并且協(xié)同工作，能提供高可靠性，高穩定性以及高可測性的多服務(wù)器例程。服務(wù)端集群對客戶(hù)端表現出來(lái)似乎就是一個(gè)單獨的服務(wù)器例程。從客戶(hù)端的視角來(lái)看，集群的客戶(hù)端和單獨的服務(wù)器沒(méi)多大不同，但是他們通過(guò)提供實(shí)效無(wú)縫轉移和SESSION復制做到了不間斷服務(wù)以及SESSION數據持久性。
集群中的服務(wù)器通訊集群中的應用程序服務(wù)器通過(guò)諸如IP多點(diǎn)傳送（IP multicast）和IP sockets這樣的技術(shù)和其他服務(wù)器共享信息
●IP多點(diǎn)傳送：主要用于1對多的服務(wù)器通訊，通過(guò)廣播服務(wù)和 heartbeats消息的可用來(lái)顯示服務(wù)器的有效
●IP sockets：主要用于在集群的服務(wù)器例程中進(jìn)行P2P服務(wù)器通訊
使用IP多點(diǎn)傳送進(jìn)行一對多通訊TOMCAT服務(wù)器使用IP多點(diǎn)傳送在集群中的服務(wù)器例程間進(jìn)行一對多的通訊，IP多點(diǎn)傳送是一種能夠讓多服務(wù)器向指定IP地址和端口號進(jìn)行訂閱并且監聽(tīng)消息的廣播技術(shù)（多點(diǎn)傳送IP地址范圍從224.0.0.0 到239.255.255.255）。在集群中的每個(gè)服務(wù)器都使用多點(diǎn)傳送廣播特定的 heartbeat消息，通過(guò)監視這些 heartbeat消息，在集群中的服務(wù)器例程判斷什么時(shí)候服務(wù)器例程失效。在服務(wù)器通訊中使用IP多點(diǎn)傳送的一個(gè)缺點(diǎn)是他不能保證這些消息被確實(shí)接收到了。例如，一個(gè)應用持續的本地多點(diǎn)傳送緩存滿(mǎn)了，就不能寫(xiě)入新的多點(diǎn)傳送消息，等消息過(guò)了之后該應用程序就沒(méi)有被通知到。
使用IP Sockets進(jìn)行服務(wù)器通訊IP sockets 同樣也通過(guò)了一套在集群中的服務(wù)器間進(jìn)行發(fā)送消息和數據的機制。服務(wù)器例程使用IP sockets 在集群節點(diǎn)間進(jìn)行HTTP SESSION狀態(tài)的復制。正確的SOKET配制對于集群的性能是至關(guān)重要的，基于SOCKET的通訊的效率取決于SOCKET的實(shí)現類(lèi)別（例如：系統使用本地的或者純JAVA SOCKET讀取器實(shí)現），如果服務(wù)器使用純JAVA SOCKET讀取器則要看服務(wù)器例程是否注冊使用了足夠的SOCKET讀取器線(xiàn)程。
如果想要有最佳的SOCKET性能，系統應該注冊使用本地的SOCEKT而不是純JAVA實(shí)現。這是因為相對于基于JAVA的SOCKET實(shí)現，本地SOCKET消耗更少的系統資源。雖然SOCKET讀取器的JAVA實(shí)現是P2P通信中一種可靠而且可移動(dòng)的方法，可是他不能為集群中的重型SOCKET使用提供最好的性能。當判斷從SOCKET是否有數據讀取的時(shí)候本地SOCKET讀取器使用了更有效率的方法。使用本地SOCKET讀取器實(shí)現，讀取器線(xiàn)程不需要去統計靜止的SOCKET：他們僅僅為活動(dòng)的SOCKET服務(wù)，并且在一個(gè)給定的SOCKET開(kāi)始活躍起來(lái)時(shí)他們可以立刻捕捉到。而使用純JAVA SOCKET讀取器，線(xiàn)程必須動(dòng)態(tài)的統計所有打開(kāi)的SOCKET，判斷他們是否包含可讀取的數據。換句話(huà)說(shuō)，SOCKET讀取器總是忙于統計SOCKET，即使這些SOCKET沒(méi)有數據可讀。這些本不應該的系統開(kāi)銷(xiāo)降低了性能。
TOMCAT 5中的集群雖然在TOMCAT5的早些版本中也有集群的功能，但是在稍后的版本中（5。0。19或者更高），集群變的更加模塊組件化。在 server.xml 中集群元素已經(jīng)被重構，這樣我們可以替換集群的不同部分而不會(huì )影響其他元素。例如，當前配置中把成員服務(wù)設置為多點(diǎn)傳送發(fā)現。這里可以輕易地把成員服務(wù)修改替換為使用TCP或者 Unicast ，而不會(huì )改變集類(lèi)邏輯的其他部分。
其他一些集群元素，例如SESSION管理器，復制發(fā)送端，復制接受端也可以被自定義的實(shí)現取代而不影響集群配置的其他部分。同樣，在TOMCAT集群中的任何服務(wù)器組件可以使用集類(lèi)API向集群中的所有成員發(fā)送消息。
SESSION復制服務(wù)器集群通常操縱兩種SESSION： sticky sessions和 replicated sessions 。sticky sessions就是存在單機服務(wù)器中的接受網(wǎng)絡(luò )請求的SESSION，其他集群成員對該服務(wù)器的SESSION狀態(tài)完全不清楚，如果存有SESSION的服務(wù)器失敗的話(huà)，用戶(hù)必須再次登陸網(wǎng)站，重新輸入所有存儲在SESSION中的數據。
另一種SESSION類(lèi)型是，在一臺服務(wù)器中SESSION狀態(tài)被復制到集群中的其他所有服務(wù)器上，無(wú)論何時(shí)，只要SESSION 被改變，SESSION數據都要重新被復制。這就是 replicated session 。 sticky 和 replicated sessions都有他們的優(yōu)缺點(diǎn)， Sticky sessions簡(jiǎn)單而又容易操作，因為我們不必復制任何SESSION數據到其他服務(wù)器上。這樣就會(huì )減少系統消耗，提高性能。但是如果服務(wù)器失敗，所有存儲在該服務(wù)器內存中的SESSION數據也同樣會(huì )消失。如果SESSION數據沒(méi)有被復制到其他服務(wù)器，這些SESSION就完全丟失了。當我們在進(jìn)行一個(gè)查詢(xún)事務(wù)當中的時(shí)候，丟失所有已經(jīng)輸入的數據，就會(huì )導致很多問(wèn)題。
為了支持 JSP HTTP session 狀態(tài)的自動(dòng)失效無(wú)縫轉移，TOMCAT服務(wù)器復制了在內存中的SESSION狀態(tài)。這是通過(guò)復制存儲在一臺服務(wù)器上的SESSION數據到集群中其他成員上防止數據丟失以及允許失效無(wú)縫轉移。
對象的狀態(tài)管理通過(guò)在服務(wù)器上的保存狀態(tài)可以區分出4種對象：
●無(wú)狀態(tài)：一個(gè)無(wú)狀態(tài)對象在調用的時(shí)候不會(huì )在內存中保存任何狀態(tài)，因為客戶(hù)端和服務(wù)器端沒(méi)必要保存任何有關(guān)對方的信息。在這種情況下，客戶(hù)端會(huì )在每次請求服務(wù)器時(shí)都會(huì )發(fā)送數據給服務(wù)器。SESSION狀態(tài)被在客戶(hù)端和服務(wù)器端來(lái)回發(fā)送。這種方法不總是可行和理想的，特別是當傳輸的數據比較大或者一些安全信息我們不想保存在客戶(hù)端的時(shí)候；
●會(huì )話(huà)：一個(gè)會(huì )話(huà)對象在一個(gè)SESSION中只被用于特定的某個(gè)客戶(hù)端。在SESSION中，他可以為所有來(lái)自該客戶(hù)端的請求服務(wù)，并且僅僅是這個(gè)客戶(hù)端的請求。貫穿一個(gè)SESSION，兩個(gè)請求間的狀態(tài)信息必須保存。會(huì )話(huà)服務(wù)通常在內存中保存短暫的狀態(tài)，當在服務(wù)器失敗的時(shí)候可能會(huì )丟失。SESSION狀態(tài)通常被保存在請求間的服務(wù)器的內存中。為了清空內存，SESSION狀態(tài)也可以被從內存中釋放（就像在一個(gè)對象CACHE）。在該對象中，性能和可量測性都有待提高，因為更新并不是被單獨的寫(xiě)到磁盤(pán)上，并且服務(wù)器失敗的時(shí)候數據也沒(méi)辦法搶救。
●緩存：緩存對象在內存中保存狀態(tài)，并且使用這個(gè)去處理從多客戶(hù)端來(lái)的請求。緩存服務(wù)的實(shí)現可以擴展到他們把緩存的是數據備份保存在后端存儲器中（通常是一個(gè)關(guān)系數據庫）。
●獨立的：一個(gè)獨立的對象在一個(gè)時(shí)間內只活躍在集群中的一臺服務(wù)器上，處理來(lái)自多客戶(hù)端的請求。他通常由那些私有的，持久的，在內存中緩寸的數據支持。他同樣也在內存中保持短暫狀態(tài)，在服務(wù)器失敗的時(shí)候要重建或者丟失。當失敗的時(shí)候，獨立對象必須在同一個(gè)服務(wù)器上重起或者移植到另一臺服務(wù)器上。
(來(lái)源: "Using WebLogic Server Clusters")
SESSION復制的設計考慮事項網(wǎng)絡(luò )考慮事項把集群的多點(diǎn)傳送地址和其他應用程序隔離是至關(guān)重要的。我們不希望集群配置或者網(wǎng)絡(luò )布局干擾到多點(diǎn)傳送服務(wù)器通信。和其他應用程序共享集群多點(diǎn)傳送地址將迫使集群的服務(wù)器例程處理不應該的消息，消耗系統內存。共享多點(diǎn)傳送地址可能也會(huì )使IP多點(diǎn)傳送緩沖過(guò)載，延遲服務(wù)器 heartbeat 消息傳輸。這樣的延遲可能導致一個(gè)服務(wù)器例程被標識為死亡，僅僅因為他的 heartbeat 消息沒(méi)有被及時(shí)接收。
編程考慮事項除了上面提到的網(wǎng)絡(luò )相關(guān)因素，還有些和我們寫(xiě) J2EE 網(wǎng)絡(luò )應用程序有關(guān)的設計考慮也會(huì )影響SESSION復制。以下列出了一些編程方面的考慮：
●SESSION數據必須被序列化：為了支持HTTP session 狀態(tài)的內存內復制，所有的 servlet 和 JSP session 數據必須被序列化，對象中的每個(gè)域都必須被序列化，這樣對象被可靠的序列化。
●把應用程序設計為冪等的：冪等的的意思就是一個(gè)操做不會(huì )修改狀態(tài)信息，并且每次操作的時(shí)候都返回同樣的結果（換句話(huà)說(shuō)就是：做多次和做一次的效果是一樣的），通常，WEB請求，特別是 HTML forms 都被發(fā)送多次（當用戶(hù)點(diǎn)擊發(fā)送按紐兩次，重載頁(yè)面多次），導致多次HTTP請求。設計SERVLET和其他WEB對象為 冪等的，可以容忍多次請求。詳細可以去參考設計模式“Synchronized Token ”和“Idempotent Receiver ”關(guān)于怎樣設計冪等的的應用程序。
●在BUSINESS層存儲狀態(tài)：會(huì )話(huà)狀態(tài)應該使用有狀態(tài)的SESSION BEANS存儲在EJB層，而不是存儲在WEB層的HttpSession。因為企業(yè)應用程序要支持各種類(lèi)型客戶(hù)端（WEB客戶(hù)端，JAVA應用程序，其他EJB），存儲數據在WEB層會(huì )導致在客戶(hù)端的雙數據存儲。因此，有狀態(tài)的SESSION BEAN在這些情況下就被用于存儲SESSION狀態(tài)。無(wú)狀態(tài)的SESSION BEAN要為每次的調用重構造會(huì )話(huà)狀態(tài)。這些狀態(tài)可能必須從數據庫中恢復的數據中重編譯。這些缺點(diǎn)失去了使用無(wú)狀態(tài)SESSION BEAN去提高性能和可測量性的目的，嚴重的減低了性能。
●序列化系統消耗：序列化SESSION數據在復制SESSION狀態(tài)的時(shí)候回會(huì )些系統消耗。隨著(zhù)序列化對象大小的增長(cháng)消耗也越多。最好是保持SESSION容量適當的小。但是如果你必須在SESSION中創(chuàng )建非常大的對象，最好測試下你的 servlets 性能以保證性能是可接受的以及SESSION的復制時(shí)間是適當的。
●用戶(hù)SESSION：判斷在集群中每個(gè)TOMCAT服務(wù)器例程所控制的并發(fā)用戶(hù)SESSION最大數是很重要的。為了控制更多并發(fā)SESSION，我們應該為提高效率添加更多內存。最大并發(fā)客戶(hù)端數，以及每個(gè)客戶(hù)端請求的頻率在決定SESSION復制對服務(wù)器的性能影響方面也是個(gè)因素。
Tomcat 5中的SESSION復制 在版本5之前，TOMCAT服務(wù)器只支持sticky sessions （使用mod_jk模塊進(jìn)行負載平衡）。如果我們需要SESSION復制，必須依靠第3方軟件例如JavaGroups 去實(shí)現。 Tomcat 5服務(wù)器帶有SESSION復制功能。和集群特征類(lèi)似，只要修改 server.xml 注冊文件就能實(shí)現SESSION復制。
Martin Fowler 在他的書(shū)《 Enterprise Patterns》中談到三個(gè)SESSION狀態(tài)持久性模式，這些模式包括：
1．客戶(hù)端SESSION狀態(tài):在客戶(hù)端存儲SESSION狀態(tài)
2．服務(wù)端SESSION狀態(tài)：在一個(gè)序列化的FORM中保持SESSION狀態(tài)到一個(gè)服務(wù)器系統上。
3．數據庫SESSION狀態(tài)：當在數據庫中提交數據的時(shí)候存儲SESSION數據。
TOMCAT支持以下三種SESSION持久性類(lèi)型：
1．內存復制：在JVM內存中復制SESSION狀態(tài)，使用TOMCAT 5安裝帶的SimpleTcpCluster 和 SimpleTcpClusterManager 類(lèi)。這些類(lèi)在包org.apache.catalina.cluster中，是server/lib/catalina-cluster.jar的一部分。
2．數據庫持久性：在這種類(lèi)型中，SESSION狀態(tài)保存在一個(gè)關(guān)系數據庫中，服務(wù)器使用JDBCManager類(lèi)從數據庫中獲取SESSION信息。這個(gè)類(lèi)在包org.apache.catalina.session.JDBCStore中，是catalina.jar的一部分。
3．基于文件的持久性：這里使用類(lèi)PersistenceManager把SESSION狀態(tài)保存到一個(gè)文件系統。這個(gè)類(lèi)在包org.apache.catalina.session.FileStore中，是catalina.jar的一部分。
TOMCAT集群元素以及SESSION復制這章簡(jiǎn)要介紹一下組成TOMCAT集群的元素以及SESSION復制。
集群：
這個(gè)是集群中的主要元素， SimpleTcpCluster類(lèi)代表這個(gè)元素。他使用在server.xml中指定的管理類(lèi)為所有可分配的web contexts生成ClusterManager。
集群管理器這個(gè)類(lèi)關(guān)注跨越集群中所有節點(diǎn)間的SESSION數據復制。所有在web.xml文件中指定了distributable標記的WEB應用程序都會(huì )有SESSION復制。集群管理器作為集群元素的managerClassName屬性在server.xml中指定。集群管理器的代碼主要被設計用來(lái)分離集群中的元素。我們所要做的就是寫(xiě)一個(gè)SESSION管理器類(lèi)去實(shí)現ClusterManager接口。這樣能讓我們靈活的使用客戶(hù)集群管理器而不會(huì )影響到集群中的其他元素。這里有兩個(gè)復制算法。SimpleTcpReplicationManager每次復制全部的SESSION，而DeltaManager只復制SESSION增量。
最簡(jiǎn)單的復制管理器在每次HTTP請求都復制所有的SESSION。在SESSION較小的時(shí)候這樣是很有用的，我們可以只用以下代碼：
HashMap map = session.getAttribute("map");
map.put("data","data");這里，我們不需要特別調用session.setAttribute() 或者 removeAttribute方法去復制SESSION變化。對于每次HTTP請求，在SESSION中的所有屬性都被復制?？梢允褂靡粋€(gè)叫做useDirtyFlag的屬性去最優(yōu)化SESSION被復制的次數。如果這個(gè)標記被設為真，我們必須調用setAttribute()方法去獲取被復制的SESSION變化。如果被設為假，每次請求后SESSION都被復制。
SimpleTcpReplicationManager生成ReplicatedSession執行SESSION復制工作。
提供增量管理器僅僅是為了性能的考慮。它在每次請求的時(shí)候都做一次復制。同時(shí)他也調用監聽(tīng)器，所以如果我們調用session.setAttribute()，那么在其他服務(wù)器上的監聽(tīng)器就會(huì )被調用。DeltaManager生成DeltaSession執行 SESSION復制。
成員成員的建立通過(guò)由TOMCAT例程在同樣的多點(diǎn)傳送IP和端口發(fā)送廣播消息。廣播的消息包括服務(wù)器的IP地址和TCP監聽(tīng)端口（默認IP地址為228.0.0.4）。
如果在給定的時(shí)間框架內一個(gè)例程沒(méi)有接收到消息（由集群配置中的mcastDropTime參數指定），成員被認為死亡。這個(gè)元素由McastService類(lèi)表示。
由mcastXXX開(kāi)始的屬性用于成員資格多點(diǎn)傳送PING。以下表格列出了用于IP多點(diǎn)傳送服務(wù)器通訊的屬性。
發(fā)送端這個(gè)元素由ReplicationTransmitter類(lèi)代表。當多點(diǎn)傳送廣播消息被接收到，成員被添加到機群。在下次復制請求前，發(fā)送例程將使用主機和端口信息建立一個(gè)TCP SOCKET。使用這些SOCKET發(fā)送序列化的數據。在TOMCAT 5中有3種不同的方法操縱SESSION復制：異步，同步，池復制模式。以下部分解釋了這些模式怎樣工作，以及他們將被使用在什么情況下。
●異步：在這種復制模式中，每個(gè)集群節點(diǎn)都有一個(gè)單線(xiàn)程扮演SESSION數據傳送器。這里，請求線(xiàn)程會(huì )把復制請求發(fā)送到一個(gè)隊列，然后返回給客戶(hù)端。在失效無(wú)縫轉移前，如果我們擁有sticky sessions，就應該使用異步復制。這里復制時(shí)間不是至關(guān)重要的，但是請求時(shí)間卻是。在異步復制期間，請求在數據被復制完之前就返回了。這種復制模式縮短了請求時(shí)間。當每個(gè)請求被分的更開(kāi)這種模式是很有用的。（例如，在WEB請求間有更長(cháng)的延遲）。同樣，如果我們不關(guān)心SESSION是否完成復制這個(gè)也很有用，當SESSION很較小時(shí)， SESSION復制時(shí)間也更短。
●同步：在這種模式中，一個(gè)單線(xiàn)程執行了HTTP請求和數據復制。集群中所有節點(diǎn)都接收到SESSION數據后線(xiàn)程才返回。同步意味被被復制的數據通過(guò)一個(gè)單SOCKET發(fā)送。由于使用一個(gè)單線(xiàn)程，同步模式可能會(huì )是簇性能的一個(gè)潛在的瓶頸。這種復制模式保證了在請求返回前SESSION 已經(jīng)被復制。
●池：TOMCAT5 在使用池復制模式進(jìn)行SESSION復制的方法上提供了很大的改進(jìn)。池模式基本上是同步模式的一個(gè)擴展版本。他基于的一個(gè)原則是：劃分服務(wù)到多例程，每個(gè)例程處理不同的SESSION數據片段。同時(shí)對接收服務(wù)器開(kāi)放多SOCKET進(jìn)行發(fā)送SESSION信息。這種方法比通過(guò)單SOCKET發(fā)送所有東西更快。因此，使用一個(gè)SOCKET池同步復制SESSION。直到所有SESSION數據都復制完請求才返回。為了有效使用這種模式要增加TCP線(xiàn)程。由于使用多SOCKET，池模式使得集群性能的逐步提高以及更好的可測性。同樣這種模式也是最安全的配置，因為它有足夠數量的SOCKET在理想的時(shí)間內發(fā)送所有的SESSION數據到其他節點(diǎn)上。而使用單SOCKET，SESSION數據在通過(guò)集群時(shí)可能丟失或者只是部分傳輸。
接收端這個(gè)集群元素由類(lèi)ReplicationListener表示。在集群配置中以tcpXXX開(kāi)始的屬性用于TCP SESSION復制。以下表格列出了用于配置服務(wù)器復制中基于SOCEKT服務(wù)器通訊的屬性。
復制值復制值用于判斷哪些HTTP請求需要被復制。由于我們不經(jīng)常復制靜態(tài)內容（例如HTML和JavaScript, stylesheets，圖像文件），我們可以使用復制值元素過(guò)濾掉靜態(tài)內容。這個(gè)值可以用于找出什么時(shí)候請求已完成以及初始化復制。
部署器部署器元素可以用于部署集群范圍的應用程序。通常，部署只部署/解除部署簇內的工作成員。所以在損壞的節點(diǎn)在啟動(dòng)時(shí)沒(méi)有WARS的復制。當watchEnabled="true"時(shí)配置器為WAR文件監視一個(gè)目錄（watchDir）。當添加一個(gè)新的WAR文件時(shí)，WAR被部署到本地例程，然后被部署到集群中的其他例程。當一個(gè)WAR文件從watchDir刪除，這個(gè)WAR被從本地和集群范圍內解除部署。
所有在TOMCAT集群結構中的元素以及他們的層次關(guān)系都在列在圖1中
圖 1. Tomcat 集群等級結構圖。單擊看原圖。
TOMCAT中SESSION復制是怎么工作的以下部分簡(jiǎn)要解釋當TOMCAT服務(wù)器啟動(dòng)或則關(guān)閉時(shí)集群節點(diǎn)怎樣分享SESSION信息，詳細信息可參考Tomcat 5 Clustering文擋。
TC-01：集群中第一個(gè)節點(diǎn)
TC-02：集群中第2個(gè)節點(diǎn)
●服務(wù)器啟動(dòng)：TC-01使用標準服務(wù)器啟動(dòng)隊列啟動(dòng)。當主機對象被創(chuàng )建，即有一個(gè)集群對象和它相關(guān)聯(lián)。當contexts被解析，如果distributable已經(jīng)在web.xml中指定，那么TOMCAT為WEB CONTEXT創(chuàng )建SESSION管理器（SimpleTcpReplicationManager 取代StandardManager）。集群將會(huì )啟動(dòng)一個(gè)成員服務(wù)（成員的一個(gè)例程）和一個(gè)復制服務(wù)。
當TC-02啟動(dòng)，他也遵循第一個(gè)成員（TC-01）同樣的隊列但是有一個(gè)不同。集群被啟動(dòng)并且創(chuàng )建一個(gè)成員關(guān)系（TC-01，TC-02）。TC-02將向TC-01請求SESSION狀態(tài)。TC-01回應該請求，在TC-2開(kāi)始監聽(tīng)HTTP請求前，TC-01發(fā)送狀態(tài)給TC-02。如果TC-01不回應，TC-02將在60秒后進(jìn)入中止狀態(tài)并且發(fā)布一個(gè)日志入口。SESSIONG 狀態(tài)發(fā)送給所有在web.xml中指定了distributable的WEB應用程序。
●創(chuàng )建SESSION：當TC-01接收到請求，一個(gè)SESSION（S1）被創(chuàng )建，處理進(jìn)入TC-01的請求和沒(méi)有SESSION復制時(shí)是一樣的。當請求完成時(shí)會(huì )有以下事件：ReplicationValve將會(huì )在回應返回給用戶(hù)前截取請求。這里，會(huì )發(fā)現SESSION已經(jīng)被改變，使用TCP復制SESSION到TC-02。
●服務(wù)器儲運損耗/關(guān)閉：當在集群中的一臺服務(wù)器失敗，維護損壞或者系統升級，其他節點(diǎn)會(huì )受到第一個(gè)節點(diǎn)已經(jīng)脫離集群的通知。TC-02從他的成員資格列刪除TC-01，并且TC-02在也不會(huì )收到有關(guān)TC-01任何變動(dòng)的通知。負載平衡將會(huì )移至TC-02，所有的SESSION由TC-02控制。
當TC-01開(kāi)始恢復，他再次遵循在服務(wù)器開(kāi)始階段描述的啟動(dòng)隊列。加入到簇中并且以所有SESSIONG的當前狀態(tài)和TC-02通訊。一旦接收到 SESSIONG狀態(tài)，也就完成了加載然后打開(kāi)它的HTTP/ mod_jk端口。所以，要等到從TC-2接受到SESSION狀態(tài)TC-01才能發(fā)送請求。
●SESSION終止：如果在第一個(gè)節點(diǎn)的一個(gè)SESSION已經(jīng)無(wú)效或則由于過(guò)期終止，無(wú)效請求將被截取，SESSION會(huì )被同其他無(wú)效SESSION放在一個(gè)隊列中。當請求完成，服務(wù)器發(fā)送SESSIONG終止消息給TC-02而不是發(fā)送已經(jīng)改變的SESSION，TC-02同樣也會(huì )把該SESSION置無(wú)效。我們可以從服務(wù)器控制臺看到SESSIONG無(wú)效的消息。無(wú)效SESSION在集群中將不會(huì )被復制，直到其他請求傳出系統并且檢查無(wú)效隊列。
結束語(yǔ)在這篇文章中，我談了有關(guān)在集群環(huán)境中的SESSION復制，以及編寫(xiě)要求在內存內SESSIONG復制的J2EE應用程序時(shí)的一些設計注意事項。我同時(shí)也討論了在TOMCAT 5容器中被指定來(lái)進(jìn)行SESSIONG復制的簇元素。在這個(gè)系列的第2部分，我們將會(huì )看看怎樣使用不同的SESSIONG 管理器和復制模式在TOMCAT集群中配置SESSIONG復制。
Srini Penchikala 是一個(gè)在Flagstar 銀行工作的信息系統主題專(zhuān)家。
