http://www.javaresearch.org/article/34682.htm
bromon原創 請尊重版權
本文主要講解JBoss cluster的基本知識以及簡單的配置方法，其間涉及了一些jboss的補充知識。
一、材料準備：
1、 JBoss 4.0.2
JBoss各個版本之間差異比較大，即使同爲jboss 4.x的版本，內部組件的版本也不一致，所以請儘量使用同一版本的server。目前已經證明可以配置cluster的版本多爲jboss 3.2.6和jboss 4.0.2。
2、 Apache 2.0.54
3、 Apache mod_jk-1-2-13-apache-2-0-54
二、安裝：
1、 jboss4.0.2與apache 2.0.54的安裝請自行搞定。假設jboss的安裝目錄爲%jboss%，apache安裝目錄爲%apache%。
2、 mod_jk的安裝。
從apache.org獲得文件mod_jk-1-2-13-apache-2-0-54.so，將該文件拷貝到%apache%/ modules。
三、jboss cluster入門
Jboss 支持如下類型的cluster：EJB、web、JNDI、JMS，我們主要了解web cluster。
Web cluster實際上可以劃分爲兩個話題：負載均衡 (load balance) 和狀態同步。它們是互相獨立的，單獨配置。
負載均衡的概念比較簡單，重要的是負載均衡的粒度。可以選擇針對每個request的均衡，或者是針對每個用戶的均衡。選擇不同的粒度，需要不同的狀態同步方式。
1、基於request的負載均衡
該種方式下，負載均衡器 (load balancer)會根據各個node的狀況，把每個http request進行分發。使用這樣的均衡策略，就必須在多個node之間複製用戶的session，實時保持整個cluster的用戶狀態同步，這種操作被稱爲session複製(session replication)。Jboss的實現原理是使用攔截器(interceptor)，根據用戶的同步策略攔截request，做同步處理後再交給server產生響應。
該方法的優點是客戶不會被綁定都具體的node，只要還有一個node存活，用戶狀態都不會丟失，cluster都能夠繼續工作。缺點是node之間通信頻繁，響應速度有影響，多併發、高頻操作的情況下性能下降比較厲害。
2、 基於用戶的負載均衡
該種方式下，當用戶發出第一個request後，負載均衡器動態的把該用戶分配到某個節點，並記錄該節點的jvm路由，以後該用戶的所有request都會被綁定這個jvm路由，用戶只會與該server發生交互，這種策略被稱爲粘性session(session sticky)。
該方法的優點是響應速度快，多個節點之間無須通信。缺點也很明顯，某個node死掉以後，它負責的所有用戶都會丟失session。
四、實戰
1、負載均衡
Jboss的負載均衡目前有兩種方案，一是使用apache的mod_jk，二是使用jboss自帶的負載均衡模塊。下面分別講解這兩種配置。
mod_jk的配置
1、 請確認%apache%/modules下已經有mod_jk-1-2-13-apache-2-0-54.so文件。
2、 修改%apache%/conf/httpd.conf 在文件末尾添加: Include conf/mod_jk2.conf
3、 在%apache%/conf下新建文件 mod_jk2.conf 文件內容如下：
# Load mod_jk module. Specify the filename
# of the mod_jk lib you’ve downloaded and
# installed in the previous section
LoadModule jk_module modules/mod_jk-1-2-13-apache-2-0-54.so
# Where to find workers.properties
JkWorkersFile conf/workers2.properties
# Where to put jk logs
JkLogFile logs/mod_jk.log
# Set the jk log level [debug/error/info]
JkLogLevel info
# Select the log format
JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "
# JkOptions indicate to send SSL KEY SIZE,
JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories
# JkRequestLogFormat set the request format
JkRequestLogFormat "%w %V %T"
JkMount /* loadbalancer
其中JkMount /* loadbalancer的意思是，把所有的請求都發給loadbalancer處理。可以通過修改url來控制發送某些request。
4、在%apache%/conf下新建文件 workers2.properties 其內容爲：
worker.list=loadbalancer,server1,server2
# Define the first node...
worker.server1.port=8009
worker.server1.host=172.16.0.116
worker.server1.type=ajp13
worker.server1.lbfactor=1
worker.server1.local_worker=1
worker.server1.cachesize=10
# Define the first node...
worker.server2.port=8009
worker.server2.host=172.16.32.88
worker.server2.type=ajp13
worker.server2.lbfactor=1
worker.server2.local_worker=1
worker.server2.cachesize=10
# Now we define the load-balancing behaviour
worker.loadbalancer.type=lb
worker.loadbalancer.balanced_workers=server1,server2
worker.loadbalancer.sticky_session=1
其中對於node的命名規則是worker.節點名.xxxx。所以上述文件定義了兩個節點：server1和server2。8009端口是jboss默認的ajp端口，另外需要注意的是worker.server2.lbfactor參數，它是節點的負載加權，它的值越大，獲得負載的機會就越大。可以根據node的硬件性能進行調整。worker.loadbalancer.sticky_session參數是指定是否使用粘性session。
所有需要負載均衡的節點，都必須在worker.loadbalancer.balanced_workers參數中列舉出來。
請記住所有node的名稱和它對應着哪臺機器，後面的配置中會使用。
嘗試啓動apache：%apache/bin/apache.exe，正常情況下沒有任何提示。如果你使用的jk是2.0的，那麼配置文件的寫法完全不同，由於mod_jk2已經停止開發，所以apache並沒有提供任何講解，對於配置文件的編寫也沒有任何指導。
Jboss自帶均衡器的配置
將文件夾%jboss%/docs/examples/varia/loadbalancer/loadbalancer.sar拷貝到%jboss%/server/all/deploy下，並且修改loadbalancer.sar/loadbalancer.sar/META-INF/jboss-service.xml，在<host>標籤中類出所有節點，在<sticky-session>標籤中指定是否使用粘性session。配置完成。
該均衡器的缺點是負載能力相對不高，配置參數太少，比如無法指定不同節點的負載加權，所以後面都以mod_jk爲例，不再講解jboss自帶的負載均衡器的內容。
負載均衡的配置基本完成，啓動jboss，其中過程中會列出DefaultPatition中所有的節點：
run.bat -c all
任何節點的關閉與啓動都會在cluster中廣播，比如加如一個新節點後，其他節點會得到以下提示：
2、session sticky配置
apache應該會以粘性session的方式分發請求。部署一個應用測試一下，你會發現粘性session沒有起作用。因爲我們還沒有給jboss配置jvm路由( jvmRoute)，apache就無法知道究竟哪些session是屬於哪個節點的。我們繼續往下：
修改server1機器上的jboss的配置文件：%jboss%/server/all/deploy/jbossweb-tomcat55.sar/ META-INF/ jboss-service.xml
在110行有：<attribute name="UseJK">false</attribute>，將它改爲true。值得注意的是在這行標籤上面有一段註釋，要求你在server.xml中必須有：
Engine name="jboss.web" jmvRoute="Node1" defaultHost="localhost"
請注意這裏有一個氣死人不償命的小bug，jboss的官方文檔把 jvmRoute寫成了jmvRoute，就是v和m兩個字母的顛倒讓我鬱悶了三天，翻遍了jboss.com和theserverside.com。都是直接拷貝的錯，吐血吐到脫水啊。
下面需要修改server1上的%jboss%/server/all/deploy/jbossweb-tomcat55.sar/ server.xml，在32行左右有：
<Engine name="jboss.web" defaultHost="localhost">
給它增加一個jvmRoute屬性：
<Engine jvmRoute="server1" name="jboss.web" defaultHost="localhost">
請注意，jvmRoute的值必須和mod_jk中的節點名字正確對應，否則無法正確路由。Cluster中的所有節點都應該做相應的配置。
Jboss的配置完成了，下面需要在你的web應用中修改配置文件，讓它支持集羣。
在WEB-INF/web.xml中加入屬性： <distributable/>
Ok，基於用戶的cluster完成了，每個用戶會綁定都某個節點上進行交互。這種綁定是如何完成的呢？原來apache把客戶分發到節點後，該節點會在用戶的session id後面加上此節點的路由名稱，變成這個樣子：
Efdfxxd98daja87daj76da2dka**,server1
有了這個標誌，就能分辨該session屬於哪個節點。
3、session replication配置
下面要做的是基於request的cluster，也就讓各個節點之間互相複製session狀態。有兩種複製模式，同步與異步。使用同步的方式，jboss會把session複製的操作和對request的響應放到一個應用事務(application transaction)，session複製完成後纔去處理request。異步複製則發送session複製的消息後馬上處理request，session複製則會稍有延遲。但是在多框架的web頁面中，這樣的集羣方式會有問題。由於frame在同一時間發出多個request，會造成一些混亂，這也是採用基於用戶的集羣方式的原因之一。
JBoss 4.0.2中採用了Jboss cache來實現session複製，實際上就是一個分佈式緩存，由於session id中包含了jvm route，所以能夠分辨session屬於哪個節點。Session的更新類似於hibernate中的樂觀鎖，有了更新之後就讓session的版本號增加，其他節點通過對比版本號來決定是否同步session狀態。
配置session replication首先需要編輯
%jboss% server/all/deploy/jbossweb-tomcat55.sar/META-INF/ jboss-service.xml，88行左右有：
<attribute name="SnapshotMode">instant</attribute>
這就是剛纔提到的複製模式，instant爲立即複製，如果設爲interval 那麼系統會在延遲一段時間再進行復制，時間長度在<attribute name="SnapshotInterval">2000</attribute>中指定，單位是毫秒。
單獨配置這一個地方還不夠，在%jboss% server/all/deploy/ tc5-cluster-service.xml中有：
<attribute name="CacheMode">REPL_ASYNC</attribute>
這裏才真正決定複製是同步的還是異步的，可以指定爲REPL_ASYNC(異步)或者REPL_SYNC(同步)。
在這個文件下面一點，還有一個config標籤，裏面指定了各個節點在進行session複製的時候如何通信，有udp和tcp兩種可選，如果使用udp方式，那麼應該將udp的lookback屬性指定爲true，因爲windows上有一個叫做media sense的東西會影響udp multicast。注意如果你不瞭解multi address的ip規則，請不要隨便修改mcast_addr的值。如果採用tcp方式的話，應該指定bind_addr的值爲本機ip，並且在TCPPING標籤的initial_hosts屬性中列出所有節點，格式是”機器名[端口號]”，比如在我們的例子中，就應該這樣配置tcp(以其中一個節點爲例)：
<config>
<TCP bind_addr="172.16.0.116" start_port="7810" loopback="true"/>
<TCPPING initial_hosts="172.16.0.116[7810],172.16.32.88[7810]" port_range="3" timeout="3500"
num_initial_members="3" up_thread="true" down_thread="true"/>
<MERGE2 min_interval="5000" max_interval="10000"/>
<FD shun="true" timeout="2500" max_tries="5" up_thread="true" down_thread="true" />
<VERIFY_SUSPECT timeout="1500" down_thread="false" up_thread="false" />
<pbcast.NAKACK down_thread="true" up_thread="true" gc_lag="100"
retransmit_timeout="3000"/>
<pbcast.STABLE desired_avg_gossip="20000" down_thread="false" up_thread="false" />
<pbcast.GMS join_timeout="5000" join_retry_timeout="2000" shun="false"
print_local_addr="true" down_thread="true" up_thread="true"/>
<pbcast.STATE_TRANSFER up_thread="true" down_thread="true"/>
</config>
JBoss的clustering版主建議儘量使用udp。不過在Sobey內部，建議使用tcp方式，經測試可能有不明物體在影響udp通信，導致Timeout異常。
在%jboss%/ server/all/deploy/ cluster-service.xml中也有關於udp和tcp的配置信息，在4.0以前版本的jboss中，會以這個文件爲主配置，4.0以後都以tc5-cluster-service.xml爲主配置。
Jboss的配置完成了，最後需要在web應用中增加配置信息，控制session複製的粒度。在WEB-INF/ jboss-web.xml中增加以下內容：
<replication-config>
<replication-trigger>SET_AND_NON_PRIMITIVE_GET</replication-trigger>
<replication-granularity>SESSION</replication-granularity>
</replication-config>
其中replication-trigger是指定哪些操作引發session的版本更新，它的取值有：
SET_AND_GET
SET_AND_NON_PRIMITIVE_GET
SET
replication-granularity是複製粒度，可以取session或attribute。如果取爲attribute有可能導致複製失敗，這是目前版本的jboss cache的一個bug，等待修正。
部署項目，測試，如果配置沒有問題，可以在%jboss%/0server/all/log/server.log中發現類似於這樣的信息：
DEBUG [org.jboss.web.tomcat.tc5.session.JBossCacheManager] check to see if needs to store and replicate session with id Im9-qpuaXppMS+xXwE3M+Q**.server1
DEBUG [org.jboss.web.tomcat.tc5.session.ClusteredSession] processSessionRepl(): session is dirty. Will increment version from: 20 and replicate.
Session replication配置的成功率比較低，情況也很複雜，請仔細操作。
五、分佈式熱部署(distributable hot deploy)
在一個節點很多的cluster中，如果部署應用的時候必須把程序文件拷貝到每個機器上的話，那實在太愚蠢了，幸好通過all啓動的jboss自動支持分佈式熱部署。把支持cluster的應用（通常需要打包成war文件），放到%jboss%/server/all/farm下，那麼處於同一cluster中的其他節點會自動下載並且部署，jboss把這個稱爲Farm deploy。如下圖：
End 2005-7-11 Released by bromon