原创重量级：JBoss 4.0.2集群指南(图)

核心提示：本文主要讲解JBoss cluster的基本知识以及简单的配置方法，其间涉及了一些jboss的补充知识，原创重量级：JBoss 4.0.2集群指南(图)，一、材料预备：1、JBoss 4.0.2JBoss各个版本之间差异比较大，即使同为jboss 4.x的版本，session复制完成后才去处理request，异步复制则

　　本文主要讲解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复制则会稍有延迟。但是