JBoss集群配置的Session复制

1.       前言

接着上一篇总结文章提出的问题，这次通过相关的mod_jk和JBoss配置来达到每个JBoss节点之间的Web应用级别的Session复制。也就是说通过配置后，如果其中一台Node A的服务器宕机了，那么另一台Node B可以正常接管Node A的会话对象信息（Session信息不会丢失）。

通常是2个大模块进行配置，一个就是负责负载均衡的mod_jk模块，另一个就是负责真正应用处理的JBoss应用配置。

2.       mod_jk配置

在jk模块的配置文件——workers.properties中有一句

#黏着session
worker.loadbalancer.sticky_session=1

 

它是指session

是否是黏着性session，如果是0则代表是非黏着性session，也就是说如果第一次的请求会话是在192.168.1.104这个节点，那么在下一次request的时候就有很大的不确定性，很有可能就到了192.168.1.106这个节点上。而黏着性session就代表着一次request，只要会话不变、浏览器不关闭。那么在这一整个的长回话session请求中，自始至终都是这一个ip上的Node为这次长久会话提供服务的，如果不是特殊原因，绝对不会将节点切换到别的机器上。如果JBoss配置了相关集群的信息，那么其中一个Node挂了，请求就会自动切换到另一个Node上去，Session信息也会复制过去，保证客户的会话信息不会丢失，这种配置实际上比较消耗资源，不过某些要求稳定性十分高的系统，就必须这么做，而且远远要比以上的纠错措施严格得多，银行系统尤为明显！通常客户使用银行客户端的时候总是抱怨处理太慢了，确实是牺牲了速度、资源，维持了稳定、可靠、安全。

1.       JBoss节点配置

笔者用的JBoss版本是jboss-5.1.0.GA。

在上次集群的配置基础上(主要就是AJP的IP地址和名称和mod_jk的对应上，还有就是另一个机器可以通过IP地址访问本机的应用)增加以下配置

修改

${JBOSS_HOME}\server\all\deploy\cluster\jgroups-channelfactory.sar\META-INF\jgroups-channelfactory-stacks.xml文件

修改292行为

 

 <TCPPING timeout="3000"
                     initial_hosts="${192.168.1.104[7810],192.168.1.106[7810]}"
                     port_range="1"
                     num_initial_members="3"/>

其中104是本机Node的ip地址，106是另一个机器Node的ip地址。端口7810是JBoss内定的。

修改374行为

<TCPPING timeout="3000"
                     initial_hosts="${192.168.1.104[7810],192.168.1.106[7810]}"
                     port_range="1"
                     num_initial_members="3"/>

 在另一台机器Node节点上，此文件修改如下

            <TCPPING timeout="3000"
                     initial_hosts="${192.168.1.106[7810],192.168.1.104[7810]}"
                     port_range="1"
                     num_initial_members="3"/>

相对于104机器，106就是ip地址进行了对换。

修改

${JBOSS_HOME}\server\ all\deploy\messaging\messaging-service.xml文件

修改20行

<attribute name="ServerPeerID">${jboss.messaging.ServerPeerID:1}</attribute>

此时只要是整数值就可以

另一个机器配置

<attribute name="ServerPeerID">${jboss.messaging.ServerPeerID:2}</attribute>

需要注意的就是不同Node的这个ID数值不能一致。

修改

${JBOSS_HOME}\server\all\deployers\jbossweb.deployer\META-INF\war-deployers-jboss-beans.xml文件，这个文件比较重要，它定义了集群session的共享级别。

找到：

<property name="useJK">false</property>

//需要去掉旁边的注释<!-- -->

改为：

<property name="useJK">true</property>

//快照模式，INSTANT只要有修改就立即复制session到其他主机，设置为INSTANT下面一项也失效
<property name="snapshotMode">INSTANT</property>

//当snapshotMode快照模式设置成Interval，那么下面生效，并且每隔1000ms复制一次快照
<property name="snapshotInterval">1000</property>

//复制粒度，有session何attribute，一般就用SESSION
<property name="replicationGranularity">SESSION</property>

//复制触发，设置成如下就可以
<property name="replicationTrigger">SET_AND_NON_PRIMITIVE_GET</property>

<property name="replicationFieldBatchMode">true</property>

在自己的项目应用的war包中的web.xml加入下面一句话

<distributable/>

将其放到最顶层，如下

<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.5" 
	xmlns="http://java.sun.com/xml/ns/javaee" 
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
	xsi:schemaLocation="http://java.sun.com/xml/ns/javaee 
	http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">
	<distributable/>
  <welcome-file-list>
    <welcome-file>index.jsp</welcome-file>
  </welcome-file-list>
</web-app>

在web.xml同一级文件夹下，加入jboss-web.xml文件，内容如下

<jboss-web>
	<replication-config>
		<replication-trigger>SET_AND_NON_PRIMITIVE_GET
    	</replication-trigger>
	<replication-granularity>
			SESSION
	</replication-granularity>
	<replication-field-batch-mode>
			True
	</replication-field-batch-mode>
	</replication-config>
</jboss-web>

万事俱备，就欠启动脚本，因为笔者的环境暂时是windows环境，所以暂时先写一个bat作为启动。在${JBOSS_HOME}\bin下建立一个run-all.bat文件，(记住：一定要以配置IP的方式启动，Session赋值才有效)内容如下：

run.bat -c all -b 192.168.1.104

如果是106 Node机器，内容如下

run.bat -c all -b 192.168.1.106

         启动后就可以实现黏着性Session复制了。

 总结

这个Session复制仅仅解决了一台Node宕机的问题：一个Node宕机了，另一个Node可以接管宕机的Session信息，有效保存了用户的会话信息。在上一篇文章提出的其他问题还有待急需解决。