前面我們對Jboss的負載均衡的安裝和基本知識進行了敘述，想必大家已經把程序安裝好了。那么現在來介紹一下配置的具體內容。首先我們來看一下JBOSS實現負載均衡的方案。包括和其他軟件的綁定使用，以及自帶負載均衡模塊的使用這兩種方案。那么現在讓我們從下文中具體了解一下。

負載均衡

Jboss的負載均衡目前有兩種方案,一是使用apache的mod_jk,二是使用jboss自帶的負載均衡模塊｡下面分別講解這兩種配置｡

mod_jk的配置

(1)､請確認%apache%\modules下已經有mod_jk-1.2.25-httpd-2.2.4.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.25-httpd-2.2.4.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｡#p#

(4)､在%apache%\conf下新建文件workers2.properties其內容為:
worker.list=loadbalancer,server1,server2

# Define the first node...  
worker.server1.port=8009 
worker.server1.host=192.168.0.1  
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=192.168.0.2  
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.balance_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并沒有提供任何講解,對于配置文件的編寫也沒有任何指導｡#p#

(5)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中廣播,比如加如一個新節點后,其他節點會得到以下提示:

(6)､Jboss負載均衡的session sticky配置

apache應該會以粘性session的方式分發請求｡部署一個應用測試一下,你會發現粘性session沒有起作用｡因為我們還沒有給jboss配置jvm路由( jvmRoute),apache就無法知道究竟哪些session是屬于哪個節點的｡我們繼續往下:

修改server1機器上的jboss的配置文件:%jboss%\server\default\deploy\jboss-web.deployer\ 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\default\deploy\jboss-web.deployer\ server.xml,在32行左右有:

<Engine name="jboss.web" defaultHost="localhost">

給它增加一個jvmRoute屬性:

<Engine name="jboss.web" defaultHost="localhost" jvmRoute="server1">

請注意,jvmRoute的值必須和mod_jk中的節點名字正確對應,否則無法正確路由｡Cluster中的所有節點都應該做相應的配置｡Jboss的配置完成了,下面需要在你的web應用中修改配置文件,讓它支持集群｡在WEB-INF\web.xml中加入屬性:<distributable/>Ok,基于用戶的cluster完成了,每個用戶會綁定都某個節點上進行交互｡這種綁定是如何完成的呢?原來apache把客戶分發到節點后,該節點會在用戶的session id后面加上此節點的路由名稱,變成這個樣子:

Efdfxxd98daja87daj76da2dka**,server1

有了這個標志,就能分辨該session屬于哪個節點｡#p#

(7)､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(同步)｡

之后Jboss負載均衡的配置在這個文件下面一點,還有一個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.

在Jboss負載均衡中Session replication配置的成功率比較低,情況也很復雜,請仔細操作｡