分布式架构高可用架构篇_02_activemq高可用集群(zookeeper+leveldb)安装、配置、高可用测试

ActiveMQ 5.9 开始，ActiveMQ 的集群实现方式取消了传统的Master-Slave 方式，增加了基于ZooKeeper + LevelDB的 Master-Slave实现方式，其他两种方式目录共享和数据库共享依然存在。

三种集群方式的对比：

(1)基于共享文件系统（KahaDB，默认）：

(2)基于 JDBC：

</persistenceAdapter>

(3)基于可复制的 LevelDB（本文采用这种集群方式）：

LevelDB 是 Google开发的一套用于持久化数据的高性能类库。LevelDB并不是一种服务,用户需要自行实现Server。是单进程的服务，能够处理十亿级别规模Key-Value 型数据，占用内存小。

<replicatedLevelDB

directory="${activemq.data}/leveldb"

replicas="3"

bind="tcp://0.0.0.0:62621"

zkAddress="localhost:2181,localhost:2182,localhost:2183"

hostname="localhost"

zkPath="/activemq/leveldb-stores"/>

</persistenceAdapter>

本文主要讲解基于 ZooKeeper 和LevelDB 搭建ActiveMQ 集群。集群仅提供主备方式的高可用集群功能，避免单点故障，没有负载均衡功能。

官方文档：http://activemq.apache.org/replicated-leveldb-store.html

集群原理图：

技术分享

高可用的原理：使用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 集群的高可用实现方式类似）

1、ActiveMQ集群部署规划：

环境：CentOS 6.6 x64 、JDK7

版本：ActiveMQ 5.11.1

ZooKeeper 集群环境：192.168.1.81:2181,192.168.1.82:2182,192.168.1.83:2183

2、防火墙打开对应的端口

edu-zk-01:

-A INPUT -m state --state NEW -m tcp -p tcp --dport 8161 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 51511 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 62621 -j ACCEPT

edu-zk-02:

-A INPUT -m state --state NEW -m tcp -p tcp --dport 8162 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 51512 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 62622 -j ACCEPT

edu-zk-03:

-A INPUT -m state --state NEW -m tcp -p tcp --dport 8163 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 51513 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 62623 -j ACCEPT

3、分别在三台主机中创建/home/yxq/activemq目录

# mkdir /home/yxq/activemq

上传 apache-activemq-5.11.1-bin.tar.gz 到/home/yxq/activemq 目录\

4、解压并按节点命名

# tar -xvf apache-activemq-5.11.1-bin.tar.gz

# cd /home/yxq/activemq

# tar -xvf apache-activemq-5.11.1-bin.tar.gz

# mv apache-activemq-5.11.1 node-0X#(X代表节点号 1、2、3，下同)

5、修改管理控制台端口（默认为 8161）可在 conf/jetty.xml 中修改，如下：

node-01 管控台端口：

node-02管控台端口：

node-03管控台端口：

6、集群配置：

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

所有节点中activemq.xml配置

node-01 中的持久化配置:

node-02 中的持久化配置:

node-03 中的持久化配置:
<persistenceAdapter>

<replicatedLevelDB directory="${activemq.data}/leveldb" replicas="3" bind="tcp://0.0.0.0:62623" zkAddress="192.168.1.81:2181,192.168.1.82:2182,192.168.1.83:2183"
hostname="edu-zk-03" zkPath="/activemq/leveldb-stores"/>
</persistenceAdapter>

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

node-01 中的消息端口配置:

node-02 中的消息端口配置:

node-03 中的消息端口配置:

7、按顺序启动 3个 ActiveMQ节点：(zookeeper集群已经启动)

# /home/yxq/activemq/node-01/bin/activemq start

# /home/yxq/activemq/node-02/bin/activemq start

# /home/yxq/activemq/node-03/bin/activemq start

监听日志：

# tail -f /home/yxq/activemq/node-01/data/activemq.log

# tail -f /home/yxq/activemq/node-02/data/activemq.log

# tail -f /home/yxq/activemq/node-03/data/activemq.log

8、集群的节点状态分析：

集群启动后对 ZooKeeper 数据的抓图

技术分享

，可以看到ActiveMQ 的有3 个节点，分别是00000000000，00000000001，00000000002。

我这里是 00000000005，00000000006，00000000007。

以下第一张图展现了 000000000005的值，可以看到elected 的值是不为空，说明这个节点是Master，

技术分享

其他两个节点是 Slave。

技术分享

分布式架构高可用架构篇_02_activemq高可用集群(zookeeper+leveldb)安装、配置、高可用测试

标签：