ActiveMQ

ActiveMQ多节点集群

引入消息队列之后该如何保证其高可用性？

基于Zookeeper和LevelDB搭建ActiveMQ集群，提供主备方式的高可用集群功能，避免单点故障。

三种集群方式：官网介绍

activemq-19

在ActiveMQ V5.6版本之后推出LevelDB的持久化引擎，它使用了自定义的索引代替常用的BTree索引，其持久化性能高于KahaDB，虽然默认的持久化方式还是KahaDB，但是LevelDB可能会是趋势。

在ActiveMQ V5.9版本还提供了基于LevelDB和Zookeeper的数据复制方式，作为Master-Slave方式的首选数据复制方案。

ZK+R LevelDB Store

从ActiveMQ V5.9开始，ActiveMQ的集群实现方式取消了传统的Master-Slave方式，增加了基于Zookeeper+LevelDB的Master-Slave实现方式，从V5.9版本后也是官网推荐的。

activemq-20

原理说明：

使用Zookeeper集群注册所有的ActiveMQ Broker但只有其中一个Broker可以提供服务，它将被视为Master，其他Broker处于待机状态被视为Slave。

如果Master因故障而不能提供服务ZooKeeper会从Slave中选举出一个Broker充当Master。

Slave连接Master并同步他们的存储状态，Slave不接受客户端连接。所有存储操作都将被复制到连接至Master的Slaves。

如果Master宕机，得到了最新更新的Slave会成为Master。故障节点在恢复会重新加入到集群中并连接Master进入Slave模式。

所有需要同步的消息操作都将等待存储状态被复制到其他法定节点的操作完成才能算完成。

所以，如果你配置了replicas=3，那么法定大小是（3/2+1）=2。Master将会存储并更新然后等待（2-1）=1个Slave存储和更新完成，才汇报success。至于为什么是2-1个，可以结合Zookeeper的watch机制、选举算法、原子广播ZAB协议。

有一个节点要作为观察者存在，当一个新的Master被选中，需要至少保障一个法定节点在线，以能够找到拥有最新状态的节点，这个节点才可以成为新的Master。

部署规划和步骤

要求关闭防火墙并保证可以ping通ActiveMQ服务器，要求具备Zookeeper集群并可以成功启动。

集群部署规划列表

主机	Zookeeper集群端口	AMQ集群Bind端口	AMQ消息TCP端口	管理控制台端口	AMQ安装目录
192.168.1.132	2191	bind=”tcp://0.0.0.0:63631”	61616	8161	/mq_node01
192.168.1.132	2192	bind=”tcp://0.0.0.0:63632”	61617	8162	/mq_node02
192.168.1.132	2193	bind=”tcp://0.0.0.0:63633”	61618	8163	/mq_node03

修改控制台端口

<!--AMQ目录/conf/jetty.xml-->
<bean id="jettyPort" class="org.apache.activemq.web.WebConsolePort" init-method="start">
    <property name="host" value="0.0.0.0" />
    <property name="port" value="8161">
</bean>

HostName映射

#hostname名字映射
vim /etc/hosts
#增加自己机器配置
192.168.1.132 mq-server

brokerName一致

1
2
3

<!--三个节点的brokerName要求全部一致-->
<!--修改每个AMQ的activemq.xml文件-->
<broker xmlns="http://activemq.apache.org/schema/core" brokerName="kuromq" dataDirectory="${activemq.data}">

持久化配置

三个节点的持久化配置要求一致，Bind根据不同MQ实例调整

<persistenceAdapter>
    <replicatedLevelDB 
        directory="${activemq.data}/leveldb" 
        replicas="3" 
        bind="tcp://0.0.0.0:63633" 
        zkAdress="localhost2191,localhost2192,localhost2193" 
        hostname="#mq-server" 
        sync="local_disk" 
        zkPath="/activemq/leveldb-stores" />
</persistenceAdapter>

修改消息端口

修改activemq.xml的消息协议的端口，调整为上述规划的端口。

然后按照顺序启动3个ActiveMQ节点，前提是Zookeeper集群已经成功启动运行。

zk集群的节点状态

1 2	#进入任意一台zookeeper目录下的bin ./zkCli.sh -server 127.0.0.1:2191

activemq-21

activemq-22

集群启动后对Zookeeper数据抓图，可以看到ActiveMQ的三个节点，分别是00000000000，00000000001，00000000002。

第二张图00000000000的值可以看到elected的值不为空，说明这个节点是Master，其他两个是Slave。

集群可用性测试

ActiveMQ的客户端只能访问Master的Broker，其他处于Slave的Broker不能访问，所以客户端连接的Broker应该使用failover协议(失败转移)。

当一个ActiveMQ节点挂掉或者一个Zookeeper节点挂掉，ActiveMQ服务依然正常运行，如果仅剩一个ActiveMQ节点，由于不能选举Master，所以ActiveMQ不能正常运行。

同样的，如果Zookeeper仅剩一个节点活动，不管ActiveMQ各个节点存活与否，ActiveMQ也不能正常提供服务，ActiveMQ集群的高可用依赖于Zookeeper集群的高可用。

1 2	//BrokerURL调整 public static final String ACTIVE_URL="failover:(tcp://192.168.1.132:61616,tcp://192.168.1.132:61617,tcp://192.168.1.132:61618)?randomize=false";

测试：3台机器中的ActiveMQ只会有一个MQ可以被客户端连接使用，在测试时可以把Master关掉，然后再重试客户端消息发送和消息还可以正常使用，则说明集群搭建正常。

最后更新： 2020年11月12日 12:20

原始链接： https://midkuro.gitee.io/2020/05/23/activemq-cluster/

赏

Kuro's Blog

坚持是一种品格

'ActiveMQ（七）多节点集群'