熱點推薦:
您现在的位置: 電腦知識網 >> 編程 >> Java編程 >> Java開源技術 >> 正文

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

2013-11-23 20:27:18  來源: Java開源技術 

  Tomcat 服務器為集群和SESSION復制提供了集成的支持本系列的第一篇文章將為大家提供SESSION持久性以及TOMCAT集群中SESSION復制的內在工作機制一個概要認識我將會討論SESSION復制在TOMCAT中是怎樣進行的以及跨越多集群節點的SESSION持久性的復制機制在第部分我會詳細討論一個帶有SESSION復制功能的TOMCAT集群的安裝例子並且比較不同的復制情形
  
  集群
  
  傳統獨立服務器(非集群的)不提供任何失效無縫轉移以及負載平衡能力當服務器失敗的時候就無法獲取整個網站的內容除非服務器被重新喚起由於服務器失效任何存儲在服務器內存中的SESSION都會丟失用戶必須重新登陸並且輸入所有由於服務器失效丟失的數據
  
  不同的是作為集群一部分的服務器則提供了可測性以及失效無縫轉移能力一個集群就是一組同步運行並且協同工作能提供高可靠性高穩定性以及高可測性的多服務器例程服務端集群對客戶端表現出來似乎就是一個單獨的服務器例程從客戶端的視角來看集群的客戶端和單獨的服務器沒多大不同但是他們通過提供實效無縫轉移和SESSION復制做到了不間斷服務以及SESSION數據持久性
  
  集群中的服務器通訊
  
  集群中的應用程序服務器通過諸如IP多點傳送(IP multicast)和IP sockets這樣的技術和其他服務器共享信息
  
  ●IP多點傳送主要用於對多的服務器通訊通過廣播服務和 heartbeats消息的可用來顯示服務器的有效
  
  ●IP sockets主要用於在集群的服務器例程中進行PP服務器通訊
  
  使用IP多點傳送進行一對多通訊
  
  TOMCAT服務器使用IP多點傳送在集群中的服務器例程間進行一對多的通訊IP多點傳送是一種能夠讓多服務器向指定IP地址和端口號進行訂閱並且監聽消息的廣播技術(多點傳送IP地址范圍從在集群中的每個服務器都使用多點傳送廣播特定的 heartbeat消息通過監視這些 heartbeat消息在集群中的服務器例程判斷什麼時候服務器例程失效在服務器通訊中使用IP多點傳送的一個缺點是他不能保證這些消息被確實接收到了例如一個應用持續的本地多點傳送緩存滿了就不能寫入新的多點傳送消息等消息過了之後該應用程序就沒有被通知到
  
  使用IP Sockets進行服務器通訊
  
  IP sockets 同樣也通過了一套在集群中的服務器間進行發送消息和數據的機制服務器例程使用IP sockets 在集群節點間進行HTTP SESSION狀態的復制正確的SOKET配制對於集群的性能是至關重要的基於SOCKET的通訊的效率取決於SOCKET的實現類別(例如系統使用本地的或者純JAVA SOCKET讀取器實現)如果服務器使用純JAVA SOCKET讀取器則要看服務器例程是否注冊使用了足夠的SOCKET讀取器線程
  
  如果想要有最佳的SOCKET性能系統應該注冊使用本地的SOCEKT而不是純JAVA實現這是因為相對於基於JAVA的SOCKET實現本地SOCKET消耗更少的系統資源雖然SOCKET讀取器的JAVA實現是PP通信中一種可靠而且可移動的方法可是他不能為集群中的重型SOCKET使用提供最好的性能當判斷從SOCKET是否有數據讀取的時候本地SOCKET讀取器使用了更有效率的方法使用本地SOCKET讀取器實現讀取器線程不需要去統計靜止的SOCKET他們僅僅為活動的SOCKET服務並且在一個給定的SOCKET開始活躍起來時他們可以立刻捕捉到而使用純JAVA SOCKET讀取器線程必須動態的統計所有打開的SOCKET判斷他們是否包含可讀取的數據換句話說SOCKET讀取器總是忙於統計SOCKET即使這些SOCKET沒有數據可讀這些本不應該的系統開銷降低了性能
  
  TOMCAT 中的集群
  
  雖然在TOMCAT的早些版本中也有集群的功能但是在稍後的版本中(或者更高)集群變的更加模塊組件化在 serverxml 中集群元素已經被重構這樣我們可以替換集群的不同部分而不會影響其他元素例如當前配置中把成員服務設置為多點傳送發現這裡可以輕易地把成員服務修改替換為使用TCP或者 Unicast 而不會改變集類邏輯的其他部分
  
  其他一些集群元素例如SESSION管理器復制發送端復制接受端也可以被自定義的實現取代而不影響集群配置的其他部分同樣在TOMCAT集群中的任何服務器組件可以使用集類API向集群中的所有成員發送消息
  
  SESSION復制
  
  服務器集群通常操縱兩種SESSION sticky sessions和 replicated sessions sticky sessions就是存在單機服務器中的接受網絡請求的SESSION其他集群成員對該服務器的SESSION狀態完全不清楚如果存有SESSION的服務器失敗的話用戶必須再次登陸網站重新輸入所有存儲在SESSION中的數據
  
  另一種SESSION類型是在一台服務器中SESSION狀態被復制到集群中的其他所有服務器上無論何時只要SESSION 被改變SESSION數據都要重新被復制這就是 replicated session sticky 和 replicated sessions都有他們的優缺點 Sticky sessions簡單而又容易操作因為我們不必復制任何SESSION數據到其他服務器上這樣就會減少系統消耗提高性能但是如果服務器失敗所有存儲在該服務器內存中的SESSION數據也同樣會消失如果SESSION數據沒有被復制到其他服務器這些SESSION就完全丟失了當我們在進行一個查詢事務當中的時候丟失所有已經輸入的數據就會導致很多問題
  
  為了支持 JSP HTTP session 狀態的自動失效無縫轉移TOMCAT服務器復制了在內存中的SESSION狀態這是通過復制存儲在一台服務器上的SESSION數據到集群中其他成員上防止數據丟失以及允許失效無縫轉移
  
  對象的狀態管理
  
  通過在服務器上的保存狀態可以區分出種對象
  
  ●無狀態一個無狀態對象在調用的時候不會在內存中保存任何狀態因為客戶端和服務器端沒必要保存任何有關對方的信息在這種情況下客戶端會在每次請求服務器時都會發送數據給服務器SESSION狀態被在客戶端和服務器端來回發送這種方法不總是可行和理想的特別是當傳輸的數據比較大或者一些安全信息我們不想保存在客戶端的時候
  
  ●會話一個會話對象在一個SESSION中只被用於特定的某個客戶端在SESSION中他可以為所有來自該客戶端的請求服務並且僅僅是這個客戶端的請求貫穿一個SESSION兩個請求間的狀態信息必須保存會話服務通常在內存中保存短暫的狀態當在服務器失敗的時候可能會丟失SESSION狀態通常被保存在請求間的服務器的內存中為了清空內存SESSION狀態也可以被從內存中釋放(就像在一個對象CACHE)在該對象中性能和可量測性都有待提高因為更新並不是被單獨的寫到磁盤上並且服務器失敗的時候數據也沒辦法搶救
  
  ●緩存緩存對象在內存中保存狀態並且使用這個去處理從多客戶端來的請求緩存服務的實現可以擴展到他們把緩存的是數據備份保存在後端存儲器中(通常是一個關系數據庫)
  
  ●獨立的一個獨立的對象在一個時間內只活躍在集群中的一台服務器上處理來自多客戶端的請求他通常由那些私有的持久的在內存中緩寸的數據支持他同樣也在內存中保持短暫狀態在服務器失敗的時候要重建或者丟失當失敗的時候獨立對象必須在同一個服務器上重起或者移植到另一台服務器上
  
  (來源: Using WebLogic Server Clusters)
  
  SESSION復制的設計考慮事項
  
  網絡考慮事項

  
  把集群的多點傳送地址和其他應用程序隔離是至關重要的我們不希望集群配置或者網絡布局干擾到多點傳送服務器通信和其他應用程序共享集群多點傳送地址將迫使集群的服務器例程處理不應該的消息消耗系統內存共享多點傳送地址可能也會使IP多點傳送緩沖過載延遲服務器 heartbeat 消息傳輸這樣的延遲可能導致一個服務器例程被標識為死亡僅僅因為他的 heartbeat 消息沒有被及時接收
  
  編程考慮事項
  
  除了上面提到的網絡相關因素還有些和我們寫 JEE 網絡應用程序有關的設計考慮也會影響SESSION復制以下列出了一些編程方面的考慮
  
  ●SESSION數據必須被序列化為了支持HTTP session 狀態的內存內復制所有的 servlet 和 JSP session 數據必須被序列化對象中的每個域都必須被序列化這樣對象被可靠的序列化
  
  ●把應用程序設計為冪等的冪等的的意思就是一個操做不會修改狀態信息並且每次操作的時候都返回同樣的結果(換句話說就是做多次和做一次的效果是一樣的)通常WEB請求特別是 HTML forms 都被發送多次(當用戶點擊發送按紐兩次重載頁面多次)導致多次HTTP請求設計SERVLET和其他WEB對象為 冪等的可以容忍多次請求詳細可以去參考設計模式Synchronized Token Idempotent Receiver 關於怎樣設計冪等的的應用程序
  
  ●在BUSINESS層存儲狀態會話狀態應該使用有狀態的SESSION BEANS存儲在EJB層而不是存儲在WEB層的HttpSession因為企業應用程序要支持各種類型客戶端(WEB客戶端JAVA應用程序其他EJB)存儲數據在WEB層會導致在客戶端的雙數據存儲因此有狀態的SESSION BEAN在這些情況下就被用於存儲SESSION狀態無狀態的SESSION BEAN要為每次的調用重構造會話狀態這些狀態可能必須從數據庫中恢復的數據中重編譯這些缺點失去了使用無狀態SESSION BEAN去提高性能和可測量性的目的嚴重的減低了性能
  
  ●序列化系統消耗序列化SESSION數據在復制SESSION狀態的時候回會些系統消耗隨著序列化對象大小的增長消耗也越多最好是保持SE
From:http://tw.wingwit.com/Article/program/Java/ky/201311/28514.html
    推薦文章
    Copyright © 2005-2013 電腦知識網 Computer Knowledge   All rights reserved.