A. java 集群
一旦在伺服器上安裝並運行了群集服務 ， 該伺服器即可加入群集。群集化操作可以減少單點故障數量，並且實現了群集化資源的高可用性。下述各節簡要介紹了群集創建和群集操作中的節點行為。
注意 ： 有關安裝群集伺服器的信息 ， 請參閱 Windows server 2003 產品家族的幫助和部署指南。
創建群集
在伺服器群集產品中含有用來在伺服器上安裝群集軟體和創建新群集的群集安裝實用工具。創建新群集時，首先在選擇作為群集的第一個成員的計算機上運行該實用工具。第一步是確定群集名稱並創建群集資料庫和初始的群集成員列表來定義新群集。 Windows server 2003 群集新增了一個群集管理設置向導以及使用 cluster.exe 命令行界面創建 （ 包括從遠程創建 ） 群集的功能。
創建群集的第二步是 ， 添加可供所有群集成員使用的共用數據存儲設備。這樣，創建的新群集將帶有一個節點、自己的本地數據存儲設備以及群集共用資源 —— 通常是磁碟或數據存儲和連接介質資源。
創建群集的最後一步是 ， 在另外將要成為群集成員的每一台計算機上運行安裝實用工具。每當將新節點添加到群集中時，新節點都會自動從群集的原始成員獲得現有群集資料庫的副本。當節點加入或形成群集時，群集服務會更新該節點私有的配置資料庫副本。
形成群集
如果伺服器運行了群集服務並且無法找到群集中的其它節點 ， 它自己可以形成一個群集。要形成群集，節點必須能夠獲得對仲裁資源的獨占權。
當最初形成群集時 ， 群集中的第一個節點將包括群集配置資料庫。每當有新節點加入群集時，新節點都會在本地獲得並保持群集配置資料庫的副本。仲裁資源用恢復日誌（其中含有同節點無關的群集配置和狀態數據）的形式存儲配置資料庫的最新版本。
在群集運行中 ， 群集服務使用仲裁恢復日誌執行以下操作 ：
• 保證只有一組活動、可相互通訊的節點才能形成群集
• 僅當某個節點可以獲得對仲裁資源的控制權時 ， 才允許它形成群集
• 僅當某個節點可以同控制仲裁資源的節點通訊時 ， 才允許它加入或留在現有群集中
從群集中的其它節點和群集服務管理介面的角度看 ， 當形成群集時 ， 群集中的每個節點可能處於三種不同狀態中的一種。事件處理器會記錄這些狀態，而事件日誌管理器會將這些狀態復制到群集的其它節點。群集服務狀態包括：
• 離線 。此時的節點不是完全有效的群集成員。該節點及其群集伺服器可能在運行，也可能未運行。
• 聯機 。此時的節點是完全有效的群集成員。它遵從群集資料庫的更新、對仲裁演算法施加自己的影響、維護心跳通訊，並可以擁有和運行資源組。
• 暫停 。此時的節點是完全有效的群集成員。它遵從群集資料庫的更新、對仲裁演算法施加自己的影響、維護心跳通訊，但它無法接受資源組。它只能支持它當前已擁有的那些資源組。之所以提供暫停狀態，是為了允許執行某些維護。大多數伺服器群集組件會將聯機和暫停視為等價的狀態。
加入群集
如果一個伺服器要加入現有群集 ， 則它必須運行群集服務並且必須成功找到群集中的其它節點。在找到其它節點後，加入的伺服器必須接受群集成員資格驗證，並獲得群集配置資料庫的副本。
加入現有群集的過程開始於 Windows Server 2003 或 Windows 2000 Service Control Manager 在節點上啟動群集服務之時。在啟動過程中，群集服務會配置並裝入該節點的本地數據設備。它並不會試圖將共用的群集數據設備作為節點聯機，因為現有群集可能正在使用這些設備。
為了查找其它節點 ， 會啟動一個發現過程。當節點發現任何群集成員時，它將執行身份驗證序列。第一個群集成員會對新加入者進行身份驗證，並且在新伺服器得到成功驗證後返回成功狀態。如果驗證不成功（未能識別待加入節點的群集成員身份，或者它使用了無效的帳戶密碼），則加入群集的請求會被拒絕。
進行成功驗證後 ， 首先聯機的群集節點會檢查加入節點上的配置資料庫副本。如果該副本已過時，對加入伺服器進行驗證的群集節點會為加入的伺服器發送該資料庫的更新副本。剛加入群集的節點在收到復制的資料庫後，可以用它查找共享資源並根據需要將它們聯機。
脫離群集
當節點關閉或群集服務被停止時 ， 節點可能脫離群集。但當節點不執行群集操作（比如不向群集配置資料庫提交更新）時，節點也可能被迫脫離（被逐出）群集。
如果節點根據預先的計劃脫離群集 ， 它會向其它所有節點成員發送 ClusterExit 消息 ， 通知它們它將脫離群集。該節點不等待任何響應就會立即進行關閉資源和所有群集連接的操作。由於其餘節點收到了退出消息，因此它們不會執行在節點意外失效或網路通訊停止時發生的重新分組過程以重新確立群集成員身份。
[ 本日：2 本周：2 本月：60 總瀏覽數：128 ] [返回上一頁] [打 印] [收 藏]
上一篇文章：故障檢測和相關鏈接
下一篇文章：windows 2000活動目錄詳解之安裝配置篇
B. 開發的JAVA WEB程序部署在伺服器集群的哪一個伺服器上
閣下在沒有分布式集群部署經驗的前提下能畫出這樣的架構圖讓人佩服
本來我是不敢回答這些問題的，因為本身我也沒有集群部署經驗，但是一來沒有人幫忙回來二來我也看過一點這些相關的書籍，所以可以把我知道的給你說下，估計能幫助你30%。
整個架構部署用到了集群部署（1:2）、動靜分離、緩存服務、拆分資料庫等高並發處理技術，屬於大型系統的模型。
據我所知，集群1:2是1負載分發器、2web伺服器，（以Apache+tomcat集群為例），那麼Director server應該安裝Apache，而Real Server應該安裝tomcat，至於java web項目在tomcat下面即可。
而你的架構圖中還有動靜分離機制，理論上靜態文件伺服器也應該有java web項目才對，不然靜態文件伺服器如何取靜態文件呢。tomcat對靜態文件處理不是很好，所以很多人推薦用Nginx作為載體。
緩存和集群資料庫我不了解，不發表任何謬論。
session會話就是指的httpsession：一個客戶端一個session會話，在客戶端與伺服器保持通信期間都會需要這個會話，所以集群伺服器一定要保存這個session。問題是客戶端的URL請求被director server均衡分發了，可能第一次訪問的是第一個real server，第二次訪問的是第四個real server，如果session只在第一個real server保存，而第四個real server就會認為客戶掉線拒絕請求，所以你要考慮四個real server用一種機制保存共享所有客戶的session。一些經典的共享session方式有：session復制、session粘連、session統一獨立存儲等。
建議看下一些集群架構方面的書籍，比如《大型網站系統與java中間件實踐》。
C. JAVA服務集群與非集群的區別
集群肯定比非集群的處理能力強，但是你們集群不快可能是處理的瓶頸不在WEB到服務端的請求上，有可能是WEB端需要集群而不是服務端，更有可能是資料庫出現處理瓶頸而不是服務端。
要根據日誌分析和監控判斷好到底慢在哪裡。
一天才30000筆業務，對服務端程序來說簡直不值一提的
D. java伺服器集群後怎麼實現數據共享
方法很多，常見的是使用zookeeper或者redis，都可以實現集群間數據的共享。
E. java 集群讀取文件
正確的做法就是不要考慮集群，你的程序應該只關注於分析自己所屬伺服器的日誌。以後需要集群的時候就伺服器各自獨立分析。如果數據需要合並，則應該是由你的持久層，而不是程序來完成，比如使用同一個資料庫或者是分布式的資料庫。
DB存成什麼格式應該是按照現有需求來。本身日誌記錄在文件里也是一種持久化，資料庫只是多了數據管理的功能，所以本質上原始數據已經都記錄下來了。之所以記錄在文件里本身是考慮到資料庫存儲的效率問題，分析之後存儲在資料庫里也是為了查詢能夠更方便。所以如果不是很明朗，就不要去推測以後這些數據能幹什麼的，這種推測幾乎是沒有意義的。記錄在資料庫里的數據應該體現成現有需求里的數據，待到以後有新需求，在程序中加入新的分析功能也不是很麻煩。
F. java支持class集群模式嗎
支持。
Java具有多線程功能，可以實現class集群模式。
分布式是指將不同的業務分布在不同的地方， 而集群指的是將幾台伺服器集中在一起，實現同一業務，分布式中的每一個節點，都可以做集群， 而集群並不一定就是分布式，分布式是以縮短單個任務的執行時間來提升效率的，而集群則是通過提高單位時間內執行的任務數來提升效率。
G. JAVA WEB項目集群部署問題
根據中間件不同部署方式也不同。tomcat下面就要分別部署了，weblogic支持分別部署，也支持統一部署（兩種方式各有優缺點，推薦分別部署）。
中間件基本上都支持session共享復制，不過實現方式可能有點區別（有的是基於容器，有的是基於memcache等等）。
H. java搭建分布式集群項目大概需要多少台伺服器
超過一台都可以叫集群，只有一台也可以算分布式，需要多少台伺服器，主要看你的項目有多少模塊，需要多高的性能。沒有什麼硬性要求，不用糾結