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

2007-09-10 11:00:43 作者: 江南白衣　來源: csdn 　標(biāo)簽:j2ee Cluster (English) 【大中小】

文章轉(zhuǎn)載自互聯(lián)網(wǎng)，如果您覺得我們侵權(quán)了，請(qǐng)聯(lián)系管理員，我們會(huì)立刻處理。

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

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

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

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

Load Balance 算法主要有輪循、權(quán)重(根據(jù)服務(wù)器硬件配置的不同)和隨機(jī)三種，但更酷的做法是基于負(fù)載(直接查探或者服務(wù)器主動(dòng)報(bào)告它們的負(fù)載)。
Health Check心跳系統(tǒng)與發(fā)現(xiàn)協(xié)議。Server一般會(huì)主動(dòng)定期多播報(bào)告自己狀態(tài)，也會(huì)Ping對(duì)方來問候平安。比如Weblogic每10秒會(huì)發(fā)送一次心跳，如果有30秒沒有收到對(duì)方服務(wù)器的心跳了(考慮到多播可能會(huì)丟失數(shù)據(jù)包)就視對(duì)方為陣亡。
Session Replication 因?yàn)闀?huì)服務(wù)器記錄與特定用戶的會(huì)話信息，Balancer應(yīng)該把同一用戶的請(qǐng)求定位到同一臺(tái)服務(wù)器上。如果該服務(wù)器失效，把該用戶和會(huì)話信息轉(zhuǎn)移到新服務(wù)器上時(shí)。
如果只要單純的load balance，不要fail over的話，使用純硬件如F5已經(jīng)足夠，不需要在軟件上做任何事情。

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

二、Web層群集

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

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

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

文中沒講的Geronimo使用的WADI，應(yīng)該也屬于這種類型，不過更為靈活，詳見Geronimo 叛逆者: 加入集群功能第1部分和第2部分。

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

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

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

三、EJB集群

從stub 調(diào)用實(shí)際EJB對(duì)象時(shí)，有三種方法實(shí)現(xiàn)負(fù)載均衡和fail over：

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

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

四、其他集群

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

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

五、Cluster的神話

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

2.小心編寫可集群的程序

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

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

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

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

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

六、延伸閱讀：