ActiveMQ笔记58-Zookeeper与Replicated LevelDB集群原理

面试题：引入消息队列后，如何保证高可用性？

基于Zookeeper和LevelDB搭建的ActiveMQ集群，集群提供主备方式的高可用集群功能，避免单点故障。

ActiveMQ官网主从介绍：http://activemq.apache.org/masterslave.html

可以看到，这里支持3种方式：共享文件系统主从、JDBC主从、可复制的LevelDB存储。

LevelDB是ActiveMQ 5.6版本之后推出的持久化引擎，它使用了自定义的索引代替常用的BTree索引，其持久化性能高于KahaDB，虽然默认方式还是KahaDB，但是LevelDB在未来可能会成为趋势。

在ActiveMQ 5.9版本还提供了基于LevelDB和Zookeeper的数据复制方式，作为Master-Slave方式的首选数据复制方案。

共享文件系统主从：http://activemq.apache.org/shared-file-system-master-slave

JDBC主从：http://activemq.apache.org/jdbc-master-slave

可复制的LevelDB存储：http://activemq.apache.org/replicated-leveldb-store.html

主要来说的是可复制的LevelDB存储。

原理说明：

使用Zookeeper集群注册所有的ActiveMQ Broker，但是只要一个Broker可以提供服务，被视为Master，其他的Broker处于待机状态被视为Slave。

如果Master因为故障不能提供服务了，Zookeeper会从Slave中选出一个Broker充当Master。在运行过程中，Slave通过连接Master，来同步它们的存储状态，Slave不接受客户端连接。所有的存储操作都将被复制到连接至Master的Slave中。如果Master宕机，得到最新更新的Slave会成为Master。故障结点在恢复后重新加入进群中作为Slave连接Master。

所有需要同步的消息操作都将等待存储状态被复制到其他法定结点操作完成才能完成。

如果配置了replicas=3，那么法定节点是(3/2)+1=2个。Master会存储并更新，然后等待(2-1)=1个Slave存储和更新完成，才汇报success。