現在有越來越多的關鍵應用和大型應用是基于J2EE 來創建的，像銀行系統和帳單系統這些關鍵應用要求有很高的可用性，而Google 和Yahoo 這樣的大型應用就需要很好的可擴展性。在如今這個聯系越來越緊密的世界，高可用性和良好的可擴展性的重要性日益突出。例如在1999 年6 月份，eBay 的服務停止了22 個小時，導致大約230 萬的拍賣被中斷，eBay 的股票也隨之下降
了9.2 個百分點。
J2EE 集群就是一種能夠提供高可用性、可擴展性以及容錯性的流行技術。但是由于在J2EE 規范中沒有對集群做出規范，各個J2EE 廠商就使用不同的方式來實現集群，這樣就給系統架構師和開發人員帶來了很多麻煩。下面就是常見的一些問題：
• 為什么帶有集群支持的商業J2EE 服務器產品如此昂貴？（是無集群支持產品的10 倍）
• 為什么在單機環境下創建的應用在集群環境中無法正常運行？
• 為什么我的應用在集群環境下運行的非常慢，但是在單機模式下卻沒有這個問題？
• 為什么我的集群應用在向其他廠商的服務器遷移時會失敗？
要理解為什么會有這些限制，最好的方法就是研究它的實現，以揭開J2EE 集群的面紗。
基本術語
在我們開始討論對于集群不同的實現之前，我想，了解一下集群技術的一些基本概念還是很有意義的。希望本章不單單是告訴你這些概念和設計問題，也同時能夠為你勾勒一下不同J2EE集群實現的框架以便于理解。
可擴展性
在一些大型系統中，很難提前預知最終用戶的數量以及他們的使用行為，所以，可擴展性就是指一個系統能夠快速適應用戶數量的增加。提高服務器處理能力的最直 接的方法就是增加硬件資源，例如CPU、內存或者硬盤等。集群是解決這個問題的另外一種方式，它使得一組服務器共同分擔繁重的任務，但對于最終用戶來說就 像一臺服務器。
高可用性
通過向單機添加硬件來擴展系統能力的方案并不可靠，因為單一的服務器存在一個單點故障。像銀行系統、帳單系統這樣的關鍵應用甚至連一分鐘的停機都不能容 許，它們需要在任何時間都是可用的，并且要能夠保證響應速度。集群技術就可以滿足這個要求，它通過加入冗余服務器使得在一個服務器出錯而停止服務的時候， 這些冗余的服務器可以繼續服務。
負載均衡
負載均衡是集群的另外一個關鍵技術，它通過將請求分發到不同的服務器來達到高可用性和高效的處理能力。負載均衡器可以是一個servlet，也可以是一個 插件（例如Linux 上的ipchains），甚至還可以是一個比較昂貴的內嵌了SSL 支持的硬件產品。為了能夠分發請求，負載均衡器還需要做一些重要的工作，例如使用“會話粘滯”技術以確保來自同一個用戶的請求會被轉發到同一個服務器；使 用“健康檢查”（或者“心跳監聽”）技術來防止將請求轉發到一個失敗的服務器；有時候負載均衡器還將參與“失敗轉移”的工作。
容錯
高可用的數據并不必是嚴格正確的數據。在J2EE 集群中，當一個服務器實例失敗了，在集群中冗余的服務器就可以處理新到的請求，這樣就保證了服務依然可用。但是在服務器失敗的那一刻，正在被處理的請求就 可能無法得到正確的數據。那么，帶有容錯功能的集群就可以確保請求所得到的數據是正確的，哪怕是服務器端出現了錯誤。
這個是怎么實現的呢？確實需要我們去進行思考！
失敗轉移
在集群中，失敗轉移是實現容錯的一個關鍵技術。當最初的節點失敗之后，在集群中選擇另外一個節點來完成處理。失敗轉移到其他節點可以通過編碼實現，也可以由平臺自動實現。
冪等方法
如果一個方法使用同樣的參數進行多次調用所得到的結果都一樣，也就是說對于該方法的調用次數不影響系統，那么這個方法就叫做“冪等方法”。例如 “getUsername()”就是一個冪等方法，而“deleteFile()”就不是冪等的。在討論 HTTP 會話失敗轉移和EJB 的失敗轉移時，冪等方法是一個很重要的概念
posted on 2009-10-05 11:59
王永慶 閱讀(239)
評論(0) 編輯 收藏 所屬分類:
設計思想