Tomcat 5集群中的SESSION復(fù)制一(圖)

2019-11-18 13:04:14

字體：大中小

供稿：網(wǎng)友

　　Tomcat 5服務(wù)器為集群和session復(fù)制提供了集成的支持。本系列的第一篇文章將為大家提供SESSION持久性以及TOMCAT集群中SESSION復(fù)制的內(nèi)在工作機制一個概要熟悉。我將會討論SESSION復(fù)制在TOMCAT5中是怎樣進(jìn)行的以及跨越多集群節(jié)點的SESSION持久性的復(fù)制機制。在第2部分，我會具體討論一個帶有SESSION復(fù)制功能的TOMCAT集群的安裝例子，并且比較不同的復(fù)制情形。
　　
　　集群
　　
　　傳統(tǒng)獨立服務(wù)器（非集群的）不提供任何失效無縫轉(zhuǎn)移以及負(fù)載平衡能力。當(dāng)服務(wù)器失敗的時候，就無法獲取整個網(wǎng)站的內(nèi)容，除非服務(wù)器被重新喚起。由于服務(wù)器失效，任何存儲在服務(wù)器內(nèi)存中的SESSION都會丟失，用戶必須重新登陸并且輸入所有由于服務(wù)器失效丟失的數(shù)據(jù)。
　　
　　不同的是，作為集群一部分的服務(wù)器則提供了可測性以及失效無縫轉(zhuǎn)移能力。一個集群就是一組同步運行并且協(xié)同工作，能提供高可靠性，高穩(wěn)定性以及高可測性的多服務(wù)器例程。服務(wù)端集群對客戶端表現(xiàn)出來似乎就是一個單獨的服務(wù)器例程。從客戶端的視角來看，集群的客戶端和單獨的服務(wù)器沒多大不同，但是他們通過提供實效無縫轉(zhuǎn)移和SESSION復(fù)制做到了不間斷服務(wù)以及SESSION數(shù)據(jù)持久性。
　　
　　集群中的服務(wù)器通訊
　　
　　集群中的應(yīng)用程序服務(wù)器通過諸如ip多點傳送（IP multicast）和IP sockets這樣的技術(shù)和其他服務(wù)器共享信息
　　
　　●IP多點傳送：主要用于1對多的服務(wù)器通訊，通過廣播服務(wù)和 heartbeats消息的可用來顯示服務(wù)器的有效
　　
　　●IP sockets：主要用于在集群的服務(wù)器例程中進(jìn)行P2P服務(wù)器通訊
　　
　　使用IP多點傳送進(jìn)行一對多通訊
　　
　　TOMCAT服務(wù)器使用IP多點傳送在集群中的服務(wù)器例程間進(jìn)行一對多的通訊，IP多點傳送是一種能夠讓多服務(wù)器向指定IP地址和端口號進(jìn)行訂閱并且監(jiān)聽消息的廣播技術(shù)（多點傳送IP地址范圍從224.0.0.0 到239.255.255.255）。在集群中的每個服務(wù)器都使用多點傳送廣播特定的 heartbeat消息，通過監(jiān)視這些 heartbeat消息，在集群中的服務(wù)器例程判定什么時候服務(wù)器例程失效。在服務(wù)器通訊中使用IP多點傳送的一個缺點是他不能保證這些消息被確實接收到了。例如，一個應(yīng)用持續(xù)的本地多點傳送緩存滿了，就不能寫入新的多點傳送消息，等消息過了之后該應(yīng)用程序就沒有被通知到。
　　
　　使用IP Sockets進(jìn)行服務(wù)器通訊
　　
　　IP sockets 同樣也通過了一套在集群中的服務(wù)器間進(jìn)行發(fā)送消息和數(shù)據(jù)的機制。服務(wù)器例程使用IP sockets 在集群節(jié)點間進(jìn)行HTTP SESSION狀態(tài)的復(fù)制。正確的SOKET配制對于集群的性能是至關(guān)重要的，基于SOCKET的通訊的效率取決于SOCKET的實現(xiàn)類別（例如：系統(tǒng)使用本地的或者純java SOCKET讀取器實現(xiàn)），假如服務(wù)器使用純JAVA SOCKET讀取器則要看服務(wù)器例程是否注冊使用了足夠的SOCKET讀取器線程。
　　
　　假如想要有最佳的SOCKET性能，系統(tǒng)應(yīng)該注冊使用本地的SOCEKT而不是純JAVA實現(xiàn)。這是因為相對于基于JAVA的SOCKET實現(xiàn)，本地SOCKET消耗更少的系統(tǒng)資源。雖然SOCKET讀取器的JAVA實現(xiàn)是P2P通信中一種可靠而且可移動的方法，可是他不能為集群中的重型SOCKET使用提供最好的性能。當(dāng)判定從SOCKET是否有數(shù)據(jù)讀取的時候本地SOCKET讀取器使用了更有效率的方法。使用本地SOCKET讀取器實現(xiàn)，讀取器線程不需要去統(tǒng)計靜止的SOCKET：他們僅僅為活動的SOCKET服務(wù)，并且在一個給定的SOCKET開始活躍起來時他們可以馬上捕捉到。而使用純JAVA SOCKET讀取器，線程必須動態(tài)的統(tǒng)計所有打開的SOCKET，判定他們是否包含可讀取的數(shù)據(jù)。換句話說，SOCKET讀取器總是忙于統(tǒng)計SOCKET，即使這些SOCKET沒有數(shù)據(jù)可讀。這些本不應(yīng)該的系統(tǒng)開銷降低了性能。
　　
　　TOMCAT 5中的集群
　　
　　雖然在TOMCAT5的早些版本中也有集群的功能，但是在稍后的版本中（5。0。19或者更高），集群變的更加模塊組件化。在 server.xml 中集群元素已經(jīng)被重構(gòu)，這樣我們可以替換集群的不同部分而不會影響其他元素。例如，當(dāng)前配置中把成員服務(wù)設(shè)置為多點傳送發(fā)現(xiàn)。這里可以輕易地把成員服務(wù)修改替換為使用TCP或者 Unicast ，而不會改變集類邏輯的其他部分。
　　
　　其他一些集群元素，例如SESSION治理器，復(fù)制發(fā)送端，復(fù)制接受端也可以被自定義的實現(xiàn)取代而不影響集群配置的其他部分。同樣，在TOMCAT集群中的任何服務(wù)器組件可以使用集類API向集群中的所有成員發(fā)送消息。
　　
　　SESSION復(fù)制
　　
　　服務(wù)器集群通常操縱兩種SESSION： sticky sessions和 replicated sessions 。sticky sessions就是存在單機服務(wù)器中的接受網(wǎng)絡(luò)請求的SESSION，其他集群成員對該服務(wù)器的SESSION狀態(tài)完全不清楚，假如存有SESSION的服務(wù)器失敗的話，用戶必須再次登陸網(wǎng)站，重新輸入所有存儲在SESSION中的數(shù)據(jù)。
　　
　　另一種SESSION類型是，在一臺服務(wù)器中SESSION狀態(tài)被復(fù)制到集群中的其他所有服務(wù)器上，無論何時，只要SESSION 被改變，SESSION數(shù)據(jù)都要重新被復(fù)制。這就是 replicated session 。 sticky 和 replicated sessions都有他們的優(yōu)缺點， Sticky sessions簡單而又輕易操作，因為我們不必復(fù)制任何SESSION數(shù)據(jù)到其他服務(wù)器上。這樣就會減少系統(tǒng)消耗，提高性能。但是假如服務(wù)器失敗，所有存儲在該服務(wù)器內(nèi)存中的SESSION數(shù)據(jù)也同樣會消失。假如SESSION數(shù)據(jù)沒有被復(fù)制到其他服務(wù)器，這些SESSION就完全丟失了。當(dāng)我們在進(jìn)行一個查詢事務(wù)當(dāng)中的時候，丟失所有已經(jīng)輸入的數(shù)據(jù)，就會導(dǎo)致很多問題。
　　
　　為了支持 jsp HTTP session 狀態(tài)的自動失效無縫轉(zhuǎn)移，TOMCAT服務(wù)器復(fù)制了在內(nèi)存中的SESSION狀態(tài)。這是通過復(fù)制存儲在一臺服務(wù)器上的SESSION數(shù)據(jù)到集群中其他成員上防止數(shù)據(jù)丟失以及答應(yīng)失效無縫轉(zhuǎn)移。
　　
　　對象的狀態(tài)治理
　　
　　通過在服務(wù)器上的保存狀態(tài)可以區(qū)分出4種對象：
　　
　　●無狀態(tài)：一個無狀態(tài)對象在調(diào)用的時候不會在內(nèi)存中保存任何狀態(tài)，因為客戶端和服務(wù)器端沒必要保存任何有關(guān)對方的信息。在這種情況下，客戶端會在每次請求服務(wù)器時都會發(fā)送數(shù)據(jù)給服務(wù)器。SESSION狀態(tài)被在客戶端和服務(wù)器端往返發(fā)送。這種方法不總是可行和理想的，非凡是當(dāng)傳輸?shù)臄?shù)據(jù)比較大或者一些安全信息我們不想保存在客戶端的時候；
　　
　　●會話：一個會話對象在一個SESSION中只被用于特定的某個客戶端。在SESSION中，他可以為所有來自該客戶端的請求服務(wù)，并且僅僅是這個客戶端的請求。貫穿一個SESSION，兩個請求間的狀態(tài)信息必須保存。會話服務(wù)通常在內(nèi)存中保存短暫的狀態(tài)，當(dāng)在服務(wù)器失敗的時候可能會丟失。SESSION狀態(tài)通常被保存在請求間的服務(wù)器的內(nèi)存中。為了清空內(nèi)存，SESSION狀態(tài)也可以被從內(nèi)存中釋放（就像在一個對象CACHE）。在該對象中，性能和可量測性都有待提高，因為更新并不是被單獨的寫到磁盤上，并且服務(wù)器失敗的時候數(shù)據(jù)也沒辦法搶救。
　　
　　●緩存：緩存對象在內(nèi)存中保存狀態(tài)，并且使用這個去處理從多客戶端來的請求。緩存服務(wù)的實現(xiàn)可以擴展到他們把緩存的是數(shù)據(jù)備份保存在后端存儲器中（通常是一個關(guān)系數(shù)據(jù)庫）。
　　
　　●獨立的：一個獨立的對象在一個時間內(nèi)只活躍在集群中的一臺服務(wù)器上，處理來自多客戶端的請求。他通常由那些私有的，持久的，在內(nèi)存中緩寸的數(shù)據(jù)支持。他同樣也在內(nèi)存中保持短暫狀態(tài)，在服務(wù)器失敗的時候要重建或者丟失。當(dāng)失敗的時候，獨立對象必須在同一個服務(wù)器上重起或者移植到另一臺服務(wù)器上。
　　
　　(來源: "Using WebLogic Server Clusters")
　　
　　SESSION復(fù)制的設(shè)計考慮事項
　　
　　網(wǎng)絡(luò)考慮事項
　　
　　把集群的多點傳送地址和其他應(yīng)用程序隔離是至關(guān)重要的。我們不希望集群配置或者網(wǎng)絡(luò)布局干擾到多點傳送服務(wù)器通信。和其他應(yīng)用程序共享集群多點傳送地址將迫使集群的服務(wù)器例程處理不應(yīng)該的消息，消耗系統(tǒng)內(nèi)存。共享多點傳送地址可能也會使IP多點傳送緩沖過載，延遲服務(wù)器 heartbeat 消息傳輸。這樣的延遲可能導(dǎo)致一個服務(wù)器例程被標(biāo)識為死亡，僅僅因為他的 heartbeat 消息沒有被及時接收。
　　
　　編程考慮事項
　　
　　除了上面提到的網(wǎng)絡(luò)相關(guān)因素，還有些和我們寫 J2EE 網(wǎng)絡(luò)應(yīng)用程序有關(guān)的設(shè)計考慮也會影響SESSION復(fù)制。以下列出了一些編程方面的考慮：
　　
　　●SESSION數(shù)據(jù)必須被序列化：為了支持HTTP session 狀態(tài)的內(nèi)存內(nèi)復(fù)制，所有的 servlet 和 JSP session 數(shù)據(jù)必須被序列化，對象中的每個域都必須被序列化，這樣對象被可靠的序列化。
　　
　　●把應(yīng)用程序設(shè)計為冪等的：冪等的的意思就是一個操做不會修改狀態(tài)信息，并且每次操作的時候都返回同樣的結(jié)果（換句話說就是：做多次和做一次的效果是一樣的），通常，WEB請求，非凡是 Html forms 都被發(fā)送多次（當(dāng)用戶點擊發(fā)送按紐兩次，重載頁面多次），導(dǎo)致多次HTTP請求。設(shè)計SERVLET和其他WEB對象為冪等的，可以容忍多次請求。具體可以去參考設(shè)計模式“Synchronized Token ”和“Idempotent Receiver ”關(guān)于怎樣設(shè)計冪等的的應(yīng)用程序。
　　
　　●在BUSINESS層存儲狀態(tài)：會話狀態(tài)應(yīng)該使用有狀態(tài)的SESSION BEANS存儲在EJB層，而不是存儲在WEB層的HttpSession。因為企業(yè)應(yīng)用程序要支持各種類型客戶端（WEB客戶端，JAVA應(yīng)用程序，其他EJB），存儲數(shù)據(jù)在WEB層會導(dǎo)致在客戶端的雙數(shù)據(jù)存儲。因此，有狀態(tài)的SESSION BEAN在這些情況下就被用于存儲SESSION狀態(tài)。無狀態(tài)的SESSION BEAN要為每次的調(diào)用重構(gòu)造會話狀態(tài)。這些狀態(tài)可能必須從數(shù)據(jù)庫中恢復(fù)的數(shù)據(jù)中重編譯。這些缺點失去了使用無狀態(tài)SESSION BEAN去提高性能和可測量性的目的，嚴(yán)重的減低了性能。
　　
　　●序列化系統(tǒng)消耗：序列化SESSION數(shù)據(jù)在復(fù)制SESSION狀態(tài)的時候回會些系統(tǒng)消耗。隨著序列化對象大小的增長消耗也越多。最好是保持SE

上一篇：基于tomcat5.5的數(shù)據(jù)庫連接池環(huán)境設(shè)置

下一篇：幾個著名java開源緩存系統(tǒng)的介紹