概述

引入消息队列之后保证其高可用：基于Zookeeper和Leveldb搭建ActiveMQ集群，集群仅提供主备方式的高可用集群功能，避免单点故障。

官方在ActiveMQ5.9之后推荐使用Replicated LevelDB的集群配置。

官方文档：http://activemq.apache.org/persistence。

使用ZooKeeper实现的Master-Slave实现方式，是对ActiveMQ进行高可用的一种有效的解决方案，高可用的原理：使用ZooKeeper（集群）注册所有的ActiveMQ Broker。只有其中的一个Broker可以对外提供服务（也就是Master节点），其他的Broker处于待机状态，被视为Slave。如果Master因故障而不能提供服务，则利用ZooKeeper的内部选举机制会从Slave中选举出一个Broker充当Master节点，继续对外提供服务。

高可用+负载均衡实现

Broker-Cluster 可以解实现载均衡，但当其中一个 Broker 突然宕掉的话，那么存在于该 Broker 上处于 Pending 状态的 message 将会丢失，无法达到高可用的目的。Master-Slave 与 Broker-Cluster 相结合的部署。

在ActiveMQ5.9中，引入了复制LevelDB存储，它处理使用Apache Zookeeper从一组配置为单个LevelDB存储的代理节点中选择一个主题服务器，然后将所有从属LevelDB存储与主数据库同步，通过将所有更新复制到主数据库，从而使它们保持最新状态，这可能会成为首选的主从配置。

主从简介

以下是可用的不同类型的主从配置：

主从类型	要求	优点	缺点
共享文件系统主从	共享文件系统，如SAN	根据需要运行尽可能多的从机，自动恢复旧主机	需要共享文件系统
JDBC主从	共享数据库	根据需要运行尽可能多的从机，自动恢复旧主机	需要共享数据库，也相对较慢，因为它无法使用高性能日志
复制的LevelDB存储	Zookeeper服务器	根据需要运行尽可能多的从机，自动恢复旧主机，非常快。	需要Zookeeper服务器

部署原理说明

官网说明：http://activemq.apache.org/replicated-leveldb-store。

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

如果Master挂了，Zookeeper会从Slave中选出一个Broker当作Master。

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

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

所有需要同步到磁盘的消息传递操作都将等待更新完成后再复制到法定仲裁节点。因此，如果将存储配置为，replicas=“3” 则仲裁大小为(3/2+1)=2。主服务器将更新存储在本地，并等待另外1个从服务器存储更新，然后再报告成功。考虑它的另一种方法是，存储将对复制节点的仲裁进行同步复制，对任何其他节点进行异步复制复制。

当选出一个新的主节点时，您还至少需要有一定数量的联机节点才能找到更新最新的节点。更新最新的节点将成为新的主节点。因此，建议您至少使用3个副本节点运行，以便可以在不造成服务中断的情况下关闭一个副本节点。

部署配置

环境和版本：CentOS7+、JDK1.8+、Zookeeper、apache-activemq-5.15.9-bin.tar.gz。

关闭防火墙并保证Windows可以ping通activemq服务器

要求具备Zookeeper或Zookeeper集群并可以成功启动。

集群部署规划：

主机	ZK端口	AMQ集群bind端口	AMQ消息TCP端口	管理控制端口
192.168.81.130	2181	bind:“tcp://0.0.0.0:63631”	61616	8161
192.168.81.130	2181	bind:“tcp://0.0.0.0:63631”	61617	8162
192.168.81.130	2181	bind:“tcp://0.0.0.0:63631”	61618	8263

部署过程

#创建3个集群的目录
mkdir /usr/local/activemq_cluster
cd /usr/local/activemq_cluster
cp -r /usr/local/activemq activemq-node01
cp -r /usr/local/activemq activemq-node02
cp -r /usr/local/activemq activemq-node03
#修改管理控制台端口
vim /usr/local/activemq-cluster/activemq-node01/conf/jetty.xml     
vim /usr/local/activemq-cluster/activemq-node02/conf/jetty.xml     
vim /usr/local/activemq-cluster/activemq-node03/conf/jetty.xml 
#hostname名字映射[可以不写，目地是为了防止IP变化之后改的配置比较多]
vim /etc/hosts
192.168.81.130 activemq-server

集群配置

#3个节点的BrokerName要求完全一致
<broker xmlns="http://activemq.apache.org/schema/core" brokerName="activemq-server" dataDirectory="${activemq.data}">
# 3个节点的持久化配置
 	<persistenceAdapter>
         <replicatedLevelDB
           directory="${activemq.data}/leveldb"
           replicas="3"
           bind="tcp://0.0.0.0:63631"
           zkAddress="192.168.81.130:2181"
           hostname="activemq-server"
           zkPath="/activemq/leveldb-stores"
           />
    </persistenceAdapter>
    <persistenceAdapter>
         <replicatedLevelDB
           directory="${activemq.data}/leveldb"
           replicas="3"
           bind="tcp://0.0.0.0:63632"
           zkAddress="192.168.81.130:2181"
           hostname="activemq-server"
           zkPath="/activemq/leveldb-stores"
           />
    </persistenceAdapter>
    <persistenceAdapter>
         <replicatedLevelDB
           directory="${activemq.data}/leveldb"
           replicas="3"
           bind="tcp://0.0.0.0:63633"
           zkAddress="192.168.81.130:2181"
           hostname="activemq-server"
           zkPath="/activemq/leveldb-stores"
           />
    </persistenceAdapter>

#修改各个节点的消息端口
vim /usr/local/activemq-cluster/activemq-node01/conf/activemq.xml
vim /usr/local/activemq-cluster/activemq-node02/conf/activemq.xml
vim /usr/local/activemq-cluster/activemq-node03/conf/activemq.xml

测试

按照顺序启动3个ActiveMQ节点，到这步前题是ZK集群已经成功启动运行。

ZK集群的节点状态说明：

连接ZK：./usr/local/zookeeper/bin/zkCli.sh

查看master：

Replicated LevelDB集群故障迁移和验证

集群可用性测试MQ的客户端只能访问Master的Broker,其它处理Slave的Broker不能访问，所有客户端连接的Broker应该使用failover协议。当一个MQ节点挂掉或者一个ZK节点挂掉，MQ服务依然正常运行，如果只剩下一个MQ节点由于不能选举Master,所有MQ不能正常运行。同样的，如果ZK只剩下一个节点活动，不管MQ节点存活，MQ也不能正常提供服务（MQ集群的高可用依赖于ZK集群的高可用）。

故障迁移干掉一台ActiveMQ，它会自动切换到另一个活着的。3台机器中的MQ只会有一个MQ可以被客户端连接使用，在测试时可以把Master关掉，然后再重试客户端消息发送和消费还可以正常使用，则说明集群正常。如现在 http://192.168.81.130:8161 可以正常访问说是这台是master。

代码测试更改brokerUrl：failover:(tcp://192.168.81.130:61616,tcp://192.168.81.130:61617,tcp://192.168.81.130:61618)

目录CONTENT

ActiveMQ集群

概述