ActiveMQ基于Zookeeper和LevelDB实现Master/Slave

ActiveMQ的Master/Slave目前支持三种实现方式：
1）Shared File System Master Slave；
2）JDBC Master Slave；
3）Replicated LevelDB Store。
对于第三种方式，ActiveMQ使用LevelDB持久化数据，并使用Zookeeper协调集群中各节点选举Master，如图所示：

Master启动后接收客户端的连接请求，其他节点作为Slave连接至Master，从Master复制持久化数据，而不接收客户端的连接请求。如果Master停止，则存有最近更新的Slave被选举为Master，原Master恢复后则成为Slave。
持久化数据需要复制到规定数量的Slave上。如果设置replicas值为3，则规定数量为(3/2+1)=2（保证超过半数），即需要复制的Slave数为2，Master会同步等待某一个Slave复制持久化数据完成，而其他Slave通过异步方式复制持久化数据。一般建议设置replicas值至少为3，即ActiveMQ集群节点数至少为3，这样即使有一个节点故障，也能保证规定数量，使得集群能够正常对外提供服务。
配置3个节点的ActiveMQ集群，修改activemq.xml，保证3个节点的brokerName相同：

此处brokerName都设置为“mp_activemq”，这样各节点启动后，通过brokerName能够自动组成集群。
另外修改activemq.xml中的持久化配置，使用LevelDB持久化数据，并配置Zookeeper：

启动3个节点，其中一个节点被选举为Master，侦听各端口接收客户端的连接请求，对外提供服务，其日志如下：

从日志中可以看出，该节点被选举为Master，而另两个节点作为Slave连接至该节点。另两个节点其中一个节点的日志如下：

其连接至Master，并从Master复制数据。
在Zookeeper的/activemq/leveldb-stores路径下记录着ActiveMQ集群各节点信息，如下：

该路径下包含三个Znode，分别对应集群各节点，从中也可以看到有一个节点被选举为Master。
客户端连接ActiveMQ集群时，采用fail-over方式，这样能保证始终连接到可用的Master节点上：

注：Replicated LevelDB Store从ActiveMQ 5.9.0开始支持，部署时Java版本为jdk 1.7。