ActiveMq学习⑨__基于zookeeper和LevelDB搭建ActiveMQ集群

引入消息中间件后如何保证其高可用？
基于zookeeper和LevelDB搭建ActiveMQ集群。集群仅提供主备方式的高可用集群功能，避免单点故障。
http://activemq.apache.org/masterslave
在这里插入图片描述
LevelDB，5.6版本之后推出了LecelDB的持久化引擎，它使用了自定义的索引代替常用的BTree索引，其持久化性能高于KahaDB，虽然默认的持久化方式还是KahaDB，但是LevelDB可能会是趋势。
在5.9版本还提供了基于LevelDB和Zookeeper的数据复制方式，作为Master-Slave方式的首选数据复制方案。

Zookeeper+LevelDB的Master-Slave

从ActiveMQ5.9开始,ActiveMQ的集群实现方式取消了传统的Masster-Slave方式。增加了基于Zookeeper+LevelDB的Master-Slave实现方式,从5.9版本后也是官网的推荐。
基于Zookeeper和LevelDB搭建ActiveMQ集群,集群仅提供主备方式的高可用集群功能,避免单点故障。
官网：http://activemq.apache.org/replicated-leveldb-store

Replicated LevelDB Store使用Apache ZooKeeper从一组配置为复制LevelDB存储的代理节点中选择一个master。然后将所有从LevelDB存储与主机同步，通过从主机复制所有更新来保持它们的最新状态。
Replicated LevelDB Store使用与LevelDB存储相同的数据文件，因此您可以随时在已复制和未复制之间切换代理配置。

官网集群原理图

在这里插入图片描述
节点仲裁是什么
ActiveMQ节点仲裁是指在ActiveMQ集群中，当某个节点失效时，其他节点需要通过选举产生一个新的主节点来保证集群的正常运行。
集群中仲裁节点的作用
节点仲裁的作用是确保集群中只有一个主节点，避免出现多个主节点导致消息重复消费或消息丢失等问题。节点仲裁通常是通过ZooKeeper来实现的，ZooKeeper会监控ActiveMQ集群中各个节点的状态，并在节点失效时进行选举产生新的主节点。

说明：
使用Zookeeper集群注册所有的ActiveMQ Broker但`只有其中一个Broker可以提供服务，它将被视为Master,其他的Broker处于待机状态被视为Slave。
如果Master因故障而不能提供服务，Zookeeper会从Slave中选举出一个Broker充当Master。Slave连接Master并同步他们的存储状态，Slave不接受客户端连接。所有的存储操作都将被复制到连接至Maste的Slaves。
如果Master宕机得到了最新更新的Slave会变成Master。故障节点在恢复后会重新加入到集群中并连接Master进入Slave模式。

所有需要同步的消息操作都将等待存储状态被复制到其他法定节点的操作完成才能完成。
所以，如给你配置了replicas=3，name法定大小是（3/2）+1 = 2。Master将会存储更新然后等待（2-1）=1个Slave存储和更新完成，才汇报success，至于为什么是2-1，阳哥的zookeeper讲解过自行复习。
有一个node要作为观察者存在。当一个新的Master被选中，你需要至少保障一个法定node在线以能够找到拥有最新状态的node，这个node才可以成为新的Master。

因此，推荐运行至少3个replica nodes以防止一个node失败后服务中断。