Jboss自帶均衡器的配置
將文件夾%jboss%\docs\examples\varia\loadbalancer\loadbalancer.sar拷貝到%jboss%\ server\all\deploy下，并且修改loadbalancer.sar\loadbalancer.sar\META-INF\jboss- service.xml，在<host>標(biāo)簽中類(lèi)出所有節(jié)點(diǎn)，在<sticky-session>標(biāo)簽中指定是否使用粘性 session。配置完成。
該均衡器的缺點(diǎn)是負(fù)載能力相對(duì)不高，配置參數(shù)太少，比如無(wú)法指定不同節(jié)點(diǎn)的負(fù)載加權(quán)，所以后面都以mod_jk為例，不再講解jboss自帶的負(fù)載均衡器的內(nèi)容。
負(fù)載均衡的配置基本完成，啟動(dòng)jboss，其中過(guò)程中會(huì)列出DefaultPatition中所有的節(jié)點(diǎn)：
run.bat -c all
2、session sticky配置
apache 應(yīng)該會(huì)以粘性session的方式分發(fā)請(qǐng)求。部署一個(gè)應(yīng)用測(cè)試一下，你會(huì)發(fā)現(xiàn)粘性session沒(méi)有起作用。因?yàn)槲覀冞€沒(méi)有給jboss配置jvm路由 ( jvmRoute)，apache就無(wú)法知道究竟哪些session是屬于哪個(gè)節(jié)點(diǎn)的。我們繼續(xù)往下：
修改server1機(jī)器上的jboss的配置文件：%jboss%\server\all\deploy\jbossweb-tomcat55.sar\ META-INF\ jboss-service.xml
在110行有：<attribute name="UseJK">false</attribute>，將它改為true。值得注意的是在這行標(biāo)簽上面有一段注釋?zhuān)竽阍趕erver.xml中必須有：
Engine name="jboss.web" jmvRoute="Node1" defaultHost="localhost"
請(qǐng)注意這里有一個(gè)氣死人不償命的小bug，jboss的官方文檔把 jvmRoute寫(xiě)成了jmvRoute，就是v和m兩個(gè)字母的顛倒讓我郁悶了三天，翻遍了jboss.com和theserverside.com。都是直接拷貝的錯(cuò)，吐血吐到脫水啊。
下面需要修改server1上的%jboss%\server\all\deploy\jbossweb-tomcat55.sar\ server.xml，在32行左右有：
<Engine name="jboss.web" defaultHost="localhost">
給它增加一個(gè)jvmRoute屬性：
<Engine jvmRoute="server1" name="jboss.web" defaultHost="localhost">
請(qǐng)注意，jvmRoute的值必須和mod_jk中的節(jié)點(diǎn)名字正確對(duì)應(yīng)，否則無(wú)法正確路由。Cluster中的所有節(jié)點(diǎn)都應(yīng)該做相應(yīng)的配置。
Jboss的配置完成了，下面需要在你的web應(yīng)用中修改配置文件，讓它支持集群。
在WEB-INF\web.xml中加入屬性： <distributable/>
Ok，基于用戶的cluster完成了，每個(gè)用戶會(huì)綁定都某個(gè)節(jié)點(diǎn)上進(jìn)行交互。這種綁定是如何完成的呢？原來(lái)apache把客戶分發(fā)到節(jié)點(diǎn)后，該節(jié)點(diǎn)會(huì)在用戶的session id后面加上此節(jié)點(diǎn)的路由名稱(chēng)，變成這個(gè)樣子：
Efdfxxd98daja87daj76da2dka**,server1
有了這個(gè)標(biāo)志，就能分辨該session屬于哪個(gè)節(jié)點(diǎn)。
3、session replication配置
下面要做的是基于request的cluster，也就讓各個(gè)節(jié)點(diǎn)之間互相復(fù)制session狀態(tài)。有兩種復(fù)制模式，同步與異步。使用同步的方式， jboss會(huì)把session復(fù)制的操作和對(duì)request的響應(yīng)放到一個(gè)應(yīng)用事務(wù)(application transaction)，session 復(fù)制完成后才去處理request。異步復(fù)制則發(fā)送session復(fù)制的消息后馬上處理request，session復(fù)制則會(huì)稍有延遲。但是在多框架的 web頁(yè)面中，這樣的集群方式會(huì)有問(wèn)題。由于frame在同一時(shí)間發(fā)出多個(gè)request，會(huì)造成一些混亂，這也是采用基于用戶的集群方式的原因之一。
JBoss 4.0.2 中采用了Jboss cache來(lái)實(shí)現(xiàn)session復(fù)制，實(shí)際上就是一個(gè)分布式緩存，由于session id中包含了jvm route，所以能夠分辨session屬于哪個(gè)節(jié)點(diǎn)。Session的更新類(lèi)似于hibernate中的樂(lè)觀鎖，有了更新之后就讓session的版本號(hào)增加，其他節(jié)點(diǎn)通過(guò)對(duì)比版本號(hào)來(lái)決定是否同步session狀態(tài)。
配置session replication首先需要編輯
%jboss% server\all\deploy\jbossweb-tomcat55.sar\META-INF\ jboss-service.xml，88行左右有：
<attribute name="SnapshotMode">instant</attribute>
這就是剛才提到的復(fù)制模式，instant為立即復(fù)制，如果設(shè)為interval 那么系統(tǒng)會(huì)在延遲一段時(shí)間再進(jìn)行復(fù)制，時(shí)間長(zhǎng)度在< attribute name="SnapshotInterval">2000</attribute>中指定，單位是毫秒。
單獨(dú)配置這一個(gè)地方還不夠，在%jboss% server\all\deploy\ tc5-cluster-service.xml中有：
<attribute name="CacheMode">REPL_ASYNC</attribute>
這里才真正決定復(fù)制是同步的還是異步的，可以指定為REPL_ASYNC(異步)或者REPL_SYNC(同步)。
在這個(gè)文件下面一點(diǎn)，還有一個(gè)config標(biāo)簽，里面指定了各個(gè)節(jié)點(diǎn)在進(jìn)行session復(fù)制的時(shí)候如何通信，有udp和tcp兩種可選，如果使用udp方式，那么應(yīng)該將udp的lookback屬性指定為true，因?yàn)閣indows上有一個(gè)叫做media sense的東西會(huì)影響 udp multicast。注意如果你不了解multi address的ip規(guī)則，請(qǐng)不要隨便修改mcast_addr的值。如果采用tcp方式的話，應(yīng)該指定bind_addr的值為本機(jī)ip，并且在TCPPING標(biāo)簽的initial_hosts屬性中列出所有節(jié)點(diǎn)，格式是”機(jī)器名[端口號(hào)]”，比如在我們的例子中，就應(yīng)該這樣配置tcp(以其中一個(gè)節(jié)點(diǎn)為例)：
<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。不過(guò)在Sobey內(nèi)部，建議使用tcp方式，經(jīng)測(cè)試可能有不明物體在影響udp通信，導(dǎo)致Timeout異常。
在%jboss%\ server\all\deploy\ cluster-service.xml中也有關(guān)于udp和tcp的配置信息，在4.0以前版本的jboss中，會(huì)以這個(gè)文件為主配置，4.0以后都以tc5-cluster-service.xml為主配置。
Jboss的配置完成了，最后需要在web應(yīng)用中增加配置信息，控制session復(fù)制的粒度。在WEB-INF\ jboss-web.xml中增加以下內(nèi)容：
<replication-config> ? <replication-trigger>SET_AND_NON_PRIMITIVE_GET</replication-trigger> ? <replication-granularity>SESSION</replication-granularity> </replication-config>
其中replication-trigger是指定哪些操作引發(fā)session的版本更新，它的取值有：
SET_AND_GET ? ? SET_AND_NON_PRIMITIVE_GETSET
replication-granularity是復(fù)制粒度，可以取session或attribute。如果取為attribute有可能導(dǎo)致復(fù)制失敗，這是目前版本的jboss cache的一個(gè)bug，等待修正。
部署項(xiàng)目，測(cè)試，如果配置沒(méi)有問(wèn)題，可以在%jboss%\0server\all\log\server.log中發(fā)現(xiàn)類(lèi)似于這樣的信息：
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配置的成功率比較低，情況也很復(fù)雜，請(qǐng)仔細(xì)操作。