ActiveMQ小记(二):基于ZooKeeper的HA方案
2016-05-02 22:51
3395 查看
从 ActiveMQ
5.9 开始,ActiveMQ 的集群实现方式取消了传统的Master-Slave 方式,增加了基于ZooKeeper
+ LevelDB的 Master-Slave实现方式,其他两种方式目录共享和数据库共享依然存在。
三种集群方式的对比:
(1)基于共享文件系统(KahaDB,默认):
(2)基于 JDBC:
(3)基于可复制的 LevelDB(本文采用这种集群方式):
LevelDB 是 Google开发的一套用于持久化数据的高性能类库。LevelDB并不是一种服务,用户需要自 行实现Server。是单进程的服务,能够处理十亿级别规模Key-Value 型数据,占用内存小。
本文主要讲解基于 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文件如下:
为了避免冲突,确保端口和连接地址不一致,如下设置:
注意:3个activemq节点中的`brokerName`必须相同,否则不能加入集群
二、zookeeper集群的搭建
可参考:http://www.cnblogs.com/yjmyzz/p/4587663.html
三、校验
1)启动zk1,zk2,zk3,以及activemq-1,activemq-2,activemq3
2)验证
为了验证是否高可用,我们采用Zooinspector对集群节点状态进行监控,Zooinspector的安装见:https://github.com/liaomengge/zooinspector
分别开启3个Zooinspector进行监控,其一图如下:
00000000004这个节点中的`elected`不为null,说明此节点为Master节点,然后,手动kill掉该Master节点,观察Zooinspector的节点状态,如下:
00000000004被kill之后,00000000005提升为Master节点,继续运行,即搭建成功。
参考文章:
http://activemq.apache.org/replicated-leveldb-store.html
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>
为了避免冲突,确保端口和连接地址不一致,如下设置:
uri | port | |
activemq-1 | tcp://0.0.0.0:51616 | 8161 |
activemq-2 | tcp://0.0.0.0:51626 | 8162 |
activemq-3 | tcp://0.0.0.0:51636 | 8163 |
二、zookeeper集群的搭建
可参考:http://www.cnblogs.com/yjmyzz/p/4587663.html
三、校验
1)启动zk1,zk2,zk3,以及activemq-1,activemq-2,activemq3
2)验证
为了验证是否高可用,我们采用Zooinspector对集群节点状态进行监控,Zooinspector的安装见:https://github.com/liaomengge/zooinspector
分别开启3个Zooinspector进行监控,其一图如下:
00000000004这个节点中的`elected`不为null,说明此节点为Master节点,然后,手动kill掉该Master节点,观察Zooinspector的节点状态,如下:
00000000004被kill之后,00000000005提升为Master节点,继续运行,即搭建成功。
参考文章:
http://activemq.apache.org/replicated-leveldb-store.html
相关文章推荐
- 第95课:通过Spark Streaming的window操作实战模拟新浪微博、百度、京东等热点搜索词案例实战
- 每日一练-----顺时针旋转矩阵
- Notepad++插件小结
- C++实现的十字链表:容器和迭代器
- 多样性的配置来源
- WPF+MVVM插件化架构-壳
- Windows10 SpringMVC中需要使用setPath()才能保证cookie保存成功
- 继续学习PS
- 读《精进 如何成为一个很厉害的人》
- bzoj 1113: [Poi2008]海报PLA
- php里面的MySql
- DFS - 单词接龙
- 第6周 C语言及程序设计提高例程-24 数组名作为函数参数
- 为啥你手机还用不上安卓6.0?
- 关于Android MVC
- opencv画图的几个函数例程
- Oracle启动和关闭
- vim cuda语法高亮
- 写给工作不久就辞职的毕业生——关于转正、定职、定级
- 别蠢到用暴露自己软肋的方式,去表达你对别人的信任