J2EE Clustering經(jīng)典范文學(xué)習

    構造Cluster是架構師們實(shí)現Scalability與High Availability 的最直接用藥。所以大家很多都會(huì )無(wú)意中使用Cluster的思想去設計自己的服務(wù)器。其實(shí)Java EE里的Clustering已經(jīng)做得很熟很爛，大家如果爛熟各家vendor對Web，EJB，JNDI，JMS，WebService....的 Cluster實(shí)現，再思考自己的爛攤子時(shí)，思路便快捷清晰，少很多與同僚們的無(wú)謂爭論。

      本站下載地址 : http://www.ntsky.com/download/document/2007-09-10/dc8746ce46924f63.html

     JavaEE Cluster的經(jīng)典范文是Sun的王昱寫(xiě)于2005年的Uncover the hood of J2EE Clustering Preface，更可貴的是dev2dev上的JadeYuan兄弟將它高質(zhì)的翻成了中文。 

 一、所謂集群            目的就是以負載均衡(Load Balance)與失敗轉移(Failover) 實(shí)現可擴展性(Scalability)和高可靠性(High Availability)，主要實(shí)現的功能：

除了Scalability 與High Availability，一個(gè)集群還應該對已有代碼的最小影響，對性能影響最小，配置與部署簡(jiǎn)單，以及運行時(shí)可監控。

 二、Web層群集 

    Balancer無(wú)非Apache/IIS插件，balance Servlet，硬件四層交換機三類(lèi)，而討論的重點(diǎn)在Session 信息的Replication 實(shí)現上，簡(jiǎn)單的分有全部服務(wù)器冗余備份，三三兩兩互為冗余備份，中央備份服務(wù)器三種模式。

              1.多服務(wù)器全冗余備份
              Tomcat的最為粗糙，最沒(méi)有擴展性的做法，不提。Sun的怪怪的replacate的內存數據庫法HADB可能也屬于這種范疇。

              2.三三兩兩互為冗余備份
              Weblogic, Jboss and WebSphere 的做法，好主流。A會(huì )有B的數據，B會(huì )有C的數據，C會(huì )有B的數據，如果A出錯，就會(huì )由C接替A的工作。這種做法的弊端是：
              1.要控制failover到備份服務(wù)器，Balancer的實(shí)現復雜度高。
              2. 如果A出錯，C就要瞬時(shí)承載A、C的操作，很可能將它壓垮，針對這點(diǎn)，Weblogic的做法是針對每個(gè)session而不是每個(gè)Server選擇備份服務(wù)器，把主備服務(wù)器A、B的名字寫(xiě)在用戶(hù)Cookie里，如果A失效后，Balancer將用戶(hù)轉到服務(wù)器C，C會(huì )根據用戶(hù)cookie記錄，從B那里獲取會(huì )話(huà)信息。
              3.相對沒(méi)有cluster的方案，需要花額外的時(shí)間和內存。

              文中沒(méi)講的Geronimo使用的WADI，應該也屬于這種類(lèi)型，不過(guò)更為靈活，詳見(jiàn)Geronimo 叛逆者: 加入集群功能第1部分 和 第2部分。

              3. 中央備份服務(wù)器
              N+ 1模式，一個(gè)中央Server存放所有的Session，如果一臺Server死了，接管的Server就從中央服務(wù)器restore相關(guān)數據?？梢杂脭祿?很多應用服務(wù)器都支持的最簡(jiǎn)單，但最慢的模式)，也可以采用內存。這種方式好處是cluster服務(wù)器上不需要冗余內存，可以failover到任意服務(wù)器，cluster服務(wù)器全死了中央服務(wù)器都不死。壞處就是如果中央服務(wù)器死了...如果中央服務(wù)器的內存不夠了.....另外，多了個(gè) restore的步驟。

        使用內存備份session時(shí)，Tomcat/JBoss使用的JavaGroups 是一個(gè)很好的工具，它的“ Group membership protocols” and “message multicast”特性都非常有用。

        另外，無(wú)論使用內存還是數據庫，都需要串行化Java對象，性能損耗厲害，所以JRun 就采用了Jini架構 ，而Tangosol Coherenc ，Terracotta這些Data Grid方案都提出了自己的session備份做法，整天顯示著(zhù)比傳統方案快多少多少。Data Grid分布式緩存本身就是很Enterprise的功能，下篇blog再詳述。 

三、EJB集群

從stub 調用實(shí)際EJB對象時(shí)，有三種方法實(shí)現負載均衡和fail over：

1. Smart Stub.在stub內維護有效列表，實(shí)現負載均衡邏輯，進(jìn)行實(shí)效檢測，BEA Weblogic and JBoss 采用。
2. IIOP Runtime Library ,Sun的JES 算法,把算法從客戶(hù)端的stub移到客戶(hù)端的IIOP Runtime
3. Interceptor Proxy，IBM做法，把算法移到了服務(wù)端，Location Service Daemon (LSD)。

在JNDI查找，EJBHome Stub查找生成EJB實(shí)例，調用EJB方法三種時(shí)候都可以實(shí)現負載均衡，對statefull,stateless,entity bean，又有不同的做法。

四、其他集群

JMS 集群，可以有多個(gè)broker組成集群(JBoss，如果要持久化Message，就要把原來(lái)嵌入式的數據庫改為共享模式)，activeMQ還支持多個(gè)消費者組成集群，但每個(gè)消費者負責同一類(lèi)的任務(wù)，比如訂單隊列的處理，Server A只處理圖書(shū)類(lèi)的訂單，或只處理《Programming Ruby 2nd》的訂單。

數據庫集群有Oracle的RAC，但JDBC本身的failover能力很低，一旦connection 中斷，resultset等對象都會(huì )失效，Weblogic的連接池會(huì )嘗試重連。

五、Cluster的神話(huà)

1.Failover可徹底避免錯誤
   JBoss的文檔用了整整一章來(lái)警告你，真的需要http session復制嗎？沒(méi)有http session可以使效率提高很多，而有了的話(huà)，并不能避免所有錯誤。失敗轉移只能在兩次調用間產(chǎn)生作用，在調用時(shí)產(chǎn)生的錯誤是無(wú)法恢復的，除非這是個(gè)冪等操作(如單純的get()，而不是put()，無(wú)論如何重復操作結果都是一樣的），否則，如果A上承載100用戶(hù)，失敗時(shí)有20個(gè)用戶(hù)正在進(jìn)行處理，則只有80個(gè)用戶(hù)能逃出生天平安轉移到B。

2.小心編寫(xiě)可集群的程序

1.http session要放能serilaze的對象，對象不要太大，變更時(shí)要顯式的setAttribute().

2. 注意Cache的使用。如果每個(gè)JVM獨立使用Cache，會(huì )否不一致，如果進(jìn)行同步，注意開(kāi)銷(xiāo)。

3.不能使用靜態(tài)變量，如在線(xiàn)用戶(hù)數，要搞成分布式的 Cache。

4.外部資源如文件系統(一臺機器上沒(méi)有另外一臺機器的文件)，存成DB或者使用SAN

5.特別服務(wù)：如timer服務(wù)，基于事件的服務(wù)，

六、延伸閱讀：

• Weblogic 9 中文文檔 ：使用 WebLogic Server 群集
• JBoss4：JBoss 4 Clustering Guide

來(lái)源：http://ntsky.com/tech/java/j2ee/2007-09-10/3f90662ab6dc76d5.html