ActiveMQ小记(二)：基于ZooKeeper的HA方案

最新推荐文章于 2021-03-07 00:09:11 发布

置顶夜行的小矮子

最新推荐文章于 2021-03-07 00:09:11 发布

阅读量2.1k

点赞数

分类专栏： ActiveMQ

本文链接：https://blog.csdn.net/liaomengge/article/details/51298699

版权

ActiveMQ 专栏收录该内容

2 篇文章 0 订阅

订阅专栏

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

三种集群方式的对比：

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

<persistenceAdapter> 
	<kahaDB directory="${activemq.data}/kahadb"/> 
</persistenceAdapter>

(2)基于 JDBC：

<bean id="mysql-ds" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close"> <property name="driverClassName" value="com.mysql.jdbc.Driver"/>
	<property name="url" value="jdbc:mysql://localhost:3306/amq?relaxAutoCommit=true"/>
	<property name="username" value="root"/>
	<property name="password" value="root"/> <property name="maxActive" value="20"/>
	<property name="poolPreparedStatements" value="true"/>
</bean>
<persistenceAdapter>
	<jdbcPersistenceAdapter dataDirectory="${activemq.data}" dataSource="#mysql-ds" createTablesOnStartup="false"/>
</persistenceAdapter>

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

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

<persistenceAdapter>
    <replicatedLevelDB
            directory="${activemq.data}/leveldb"
            replicas="3"
            bind="tcp://0.0.0.0:0"
            zkAddress="127.0.0.1:2181,127.0.0.1:2182,127.0.0.1:2183"
            zkSessionTimeout="2s"
            hostname="lmg-zk-01"
            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 集群的高可用实现方式类似）

一、activemq集群配置

前提：环境的搭建，均一台机器上

准备好3份activemq可执行的文件，

1）分别修改conf/activemq.xml，conf/jetty.xml文件如下:

<persistenceAdapter>
    <replicatedLevelDB
            directory="${activemq.data}/leveldb"
            replicas="3"
            bind="tcp://0.0.0.0:0"
            zkAddress="127.0.0.1:2181,127.0.0.1:2182,127.0.0.1:2183"
            zkSessionTimeout="2s"
            hostname="lmg-zk-01"
            zkPath="/activemq/leveldb-stores"/>
</persistenceAdapter>

为了避免冲突，确保端口和连接地址不一致，如下设置：