ActiveMQ（二）ActiveMQ集群部署与应用

本文主要讲解ActiveMQ的集群部署及主从切换演示，单机版部署及入门请移步ActiveMQ（一）单机部署与应用，本篇内容需要使用zookeeper集群做支撑，未搭建zookeeper集群的朋友请看我的另一篇文章zookeeper单机-集群安装详解

简介

在高并发、对稳定性要求极高的系统中，高可用的是必不可少的，当然ActiveMQ也有自己的集群方案。从ActiveMQ 5.9开始，ActiveMQ的集群实现方式取消了传统的Master-Slave方式，增加了基于ZooKeeper + LevelDB 的 Master-Slave 实现方式

ActiveMQ3种集群方式对比

（一）基于共享文件系统（KahaDB，默认）

activemq.xml默认

（二）基于JDBC持久化

（三）基于可复制的LevelDB（google开发类库，非服务）

  #在zookeeper中集群相关数据存放路径

本文主要讲解基于ZooKeeper和LevelDB搭建ActiveMQ集群，集群仅提供集群功能，避免单点故障，没有负载均衡功能，负载均衡后续更新

高可用原理

使用ZooKeeper（集群）注册所有的ActiveMQ Broker。只有其中的一个Broker可以提供服务，被视为Master，其他的Broker（节点）处于待机状态，被视为Slave。如果Master因故障而不能提供服务，ZooKeeper会从Slave中选举出一个Broker充当Master
Slave连接Master并同步他们的存储状态，Slave不接受客户端连接。所有的存储操作都将被复制到连接至Master的Slaves。如果Master宕了，得到了最新的Slave会成为Master。故障节点在回复后会重新加入到集群中并连接Master进入Slave模式。

所有需同步的disk的消息操作都将等待存储状态被复制到其他法定节点的操作完成才能完成。所以，如果你配置了replicas=3，那么法定大小是（3/2）+1=2。Master将会存储并更新然后等待（2-1）=1个Slave存储和更新完成，才汇报success。至于为什么是2-1，熟悉Zookeeper的应该知道，有一个node要作为观察者存在。当一个新的Master被选中，你需要至少保障一个法定node在线以能够找到拥有最新状态的node。这个node可以成为新的Master。因此，推荐运行至少3个replica nodes，以防止一个node失败了，服务中断。（原理与Zookeeper集群的高可用实现方式类似）

Mq只有Master提供Client服务

集群部署

. 规划

环境：CentOS7_64、JDK7
版本：ActiveMQ 5.9
ZooKeeper集群环境：192.168.2.10:2181、 192.168.2.30:2182 、192.168.40:2183

主机	集群端口	消息端口	管控台端口	节点安装目录
192.168.2.10	62621	51511	8161	/home/lenovo/install/activemq-01
192.168.2.30	62622	51512	8162	/home/lenovo/install/activemq-03
192.168.2.40	62623	51513	8163	/home/lenovo/install/activemq-04

1、 防火墙打开对应端口
2、 在3台虚拟机中部署好单节点的mq
3、 修改管理控制台端口（默认为8161）可在conf/jetty.xml中修改，如下：

#activemq-01

         
    
    


#activemq-02

         
    
    


#activemq-03

         
    
    

4、集群配置
在3个ActiveMQ节点配置conf/activemq.xml持久化适配器。修改其中bind、zkAddress、hostname和zkPath。注意：每个activemq的BrokerName必须相同，否则不能加入集群。

在原有的基础上修改即可

修改brokerName为platform_app（可改可不改）
最为重要的是修改persistenceAdapter部分，将其默认的注释，加入如下：

#activemq-01





#activemq-02





#activemq-03

修改各节点的消息端口（注意：避免端口冲突）

 #activemq-01:改为51511
    
        
        
        
        
        
        
    

#activemq-02:改为51512
    
        
        
        
        
        
        
    

 #activemq-03:改为51513
    
        
        
        
        
        
        
    

启动服务并监听日志（需先启动zookeeper集群服务）

[lenovo@localhost bin]$ activemq-01/bin/activemq start
[lenovo@localhost bin]$ activemq-02/bin/activemq start
[lenovo@localhost bin]$ activemq-03/bin/activemq start

[lenovo@localhost bin]$ tail -f activemq-01/data/activemq.log
[lenovo@localhost bin]$ tail -f activemq-02/data/activemq.log
[lenovo@localhost bin]$ tail -f activemq-03/data/activemq.log

输出如下INFO信息则表示配置成功

日志信息

集群节点分析

运行zookeeper工具进行监控，查看集群抓取图，工具我已上传至：链接：http://pan.baidu.com/s/1pL0k1vH 密码：yufo
本地若配置了java环境可以直接运行build下的jar

随机连接一台服务

连接后下图可以看到ActiveMQ有3个节点，其中0000000000节点的elected值不为空且address路径也不为空，可以确定为是master，这里3台的文件路径为之前设置的zkPath，app_id是之前设置好了的“platform_app”

master节点

slave节点

web管理控制台查看

下面3台机器中我们只能查看一台master服务器能访问，原理在介绍部分说过，所有的slave只有复制功能，一旦master宕机，slave选举出的master将能够访问，这里我就不做测试了

8161端口服务——很明显为slave节点

8162端口服务——也为slave节点

8163端口服务——master节点

高可用测试

注：我的另外一篇文章有讲述该测试项目的结构，这里我将项目配置修改便于测试，集群代码地址：链接：http://pan.baidu.com/s/1nuANGnf 密码：p5dk

java代码配置failover连接

ActiveMQ的客户端只能访问Master的Broker，其他处于slave的broker不能访问。所以客户端连接Broker使用failover（失败转移）协议，即谁正常就连谁。

接下来开启，MQConsumer监听，使用MQProducerTest每隔300ms发一次消息

消息发送测试

Consumer成功连接master

不断发送信息

然后不断刷新管控台，这时就能看到消息不断被消费掉

管控台在不断刷新消费

接下来我们进行高可用测试，使master宕机，然后观察日志信息

master宕机后快速选举出新的master

上图我们可以看到，宕机后新的master被选举出来，通过打印信息可以看到业务数据没有任何丢失的情况

刷新监控工具，master已经被成功选举

观察管控台可以看到http ://192.168.2.40:8163/不能进行访问，http ://192.168.2.30:8162/能够进行访问，因为master被重新进行选举，所以8162端口成为了master

注：这里只剩下两台机器，若此时出现继续宕机的情况，那么slave将不能进行选举。

现在让宕机的那台机器重新恢复，让它继续加入集群充当slave角色

刷新监控工具查看

当一个ActiveMQ节点挂掉，或者一个ZooKeeper节点挂掉，ActiveMQ服务依然正常运转。如果仅剩一个ActiveMQ节点，因为不能选举Master，ActiveMQ不能正常运转；同样的，如果ZooKeeper仅剩一个节点活动，不管ActiveMQ各节点是否存活，ActiveMQ也不能正常提供服务。
（ActiveMQ集群的高可用，依赖于ZooKeeper集群的高可用。）

以上内容为参考网络教程亲自试验后的情况，希望能帮助到真正学习的朋友