本实验要求首先完成《配置JMS》、《集群配置》和《为集群配置Apache代理》。
在WebLogic Server中，JMS Server是依附于Managed Server而运行的，不能独立运行，因此也就不存在把JMS Server 部署到集群上的这种设置。
每一个JMS Server上有各种JMS 资源如Queue和Topic；且每一种JMS资源都是pinned to JMS Server的。所以，普通的JMS资源无法实现集群下的负载均衡和容错功能。
JMS集群是通过配置Distributed JMS资源来实现的，比如distributed Queue。
一个Distributed Queue是一个虚拟的JMS资源，即并没有一个物理的JMS Queue对应它。
它是通过在每一个JMS Server上创建一个物理的JMS Queue来实现负载均衡的。
注意，这些JMS Server对应的Managed Server是属于一个集群的。
用户并不知道消息是发送到了哪些物理Queue中（他不需要知道），他只知道是发送到了Distributed Queue中。
设计图如下：
具体设置步骤如下：
1. 把message应用部署到集群上。
2. 创建JMS Server: dizzyworldJMSServer2，部署到dizzy2上。
3. 创建JMS Module: dizzyworldClusterJMSModule，部署到集群上。
4. 在dizzyworldClusterJMSModule中创建Subdeployments：dizzyworldClusterSubdeployment，部署到集群上。
5. 在dizzyworldClusterJMSModule中创建Distributed Queue：dizzyworldDistributedQueue，部署到dizzyworldClusterSubdeployment上。
点击dizzyworldDistributedQueue，查看其Member成员，会发现在JMS Server和Server2中各自创建了一个Queue。
这些Queue才是真正的物理Queue。
6. 在dizzyworldClusterJMSModule中创建Connection Factory：dizzyworldConnectionFactory，部署到dizzyworldClusterSubdeployment上。
点击dizzyworldConnectionFactory，选择Configuration-->Load Balance中，在不要选中“Server Affinity Enabled”。
这样做是为了“去亲属化”，否则每个JMS Server会优先考虑把消息放到自己的Queue中。
7. 运行http://localhost/message。
向dizzyworldDistributedQueue中发送三条不一样的信息。
8. 在Console中，点击dizzyworldDistributedQueue，选择Monitor:
会看到两个JMS Server上的Queue中收到了消息。
注意，处理请求的Managed Server，与消息是否发送到该Server所对应的JMS Server没有必然关系。
比如，我的实验结果是：dizzy2处理了2个请求，dizzy1处理了1个请求，但是JMS Server2中的Queue只有1条消息，而JMS Server中的Queue有2条消息。
这应该是“Server Affinity Enabled”选项的作用。
没有评论:
发表评论