前面我们对Jboss的负载均衡的安装和基本知识进行了叙述，想必大家已经把程序安装好了。那么现在来介绍一下配置的具体内容。首先我们来看一下JBOSS实现负载均衡的方案。包括和其他软件的绑定使用，以及自带负载均衡模块的使用这两种方案。那么现在让我们从下文中具体了解一下。

　　负载均衡

　　Jboss的负载均衡目前有两种方案,一是使用apache的mod_jk,二是使用jboss自带的负载均衡模块｡下面分别讲解这两种配置｡

　　mod_jk的配置

　　(1)､请确认%apache%modules下已经有mod_jk-1.2.25-httpd-2.2.4.so文件｡

　　(2)､修改%apache%confhttpd.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｡

　　（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:%apachebinapache.exe,正常情况下没有任何提示｡如果你使用的jk是2.0的,那么配置文件的写法完全不同,由于mod_jk2已经停止开发,所以apache并没有提供任何讲解,对于配置文件的编写也没有任何指导｡

　　(5)Jboss自带均衡器的配置

　　将文件夹%jboss%docsexamplesvarialoadbalancerloadbalancer.sar拷贝到%jboss%serveralldeploy下,并且修改loadbalancer.sarloadbalancer.sarMETA-INFjboss-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%serverdefaultdeployjboss-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%serverdefaultdeployjboss-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-INFweb.xml中加入属性:<distributable/>Ok,基于用户的cluster完成了,每个用户会绑定都某个节点上进行交互｡这种绑定是如何完成的呢?原来apache把客户分发到节点后,该节点会在用户的session id后面加上此节点的路由名称,变成这个样子:

以下是引用片段： Efdfxxd98daja87daj76da2dka**,server1

　　有了这个标志,就能分辨该session属于哪个节点｡

　　(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% serveralldeployjbossweb-tomcat55.sarMETA-INF jboss-service.xml,88行左右有:  <attribute name=”SnapshotMode”>instant</attribute> 这就是刚才提到的复制模式,instant为立即复制,如果设为interval 那么系统会在延迟一段时间再进行复制,时间长度在<attribute name=”SnapshotInterval”>2000</attribute>中指定,单位是毫秒｡单独配置这一个地方还不够,在%jboss% serveralldeploy 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% serveralldeploy cluster-service.xml中也有关于udp和tcp的配置信息,在4.0以前版本的jboss中,会以这个文件为主配置,4.0以后都以tc5-cluster-service.xml为主配置｡

　　Jboss的配置完成了,最后需要在web应用中增加配置信息,控制session复制的粒度｡在WEB-INFjboss-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%serveralllogserver.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配置的成功率比较低,情况也很复杂,请仔细操作｡