基于zookeeper+leveldb搭建activemq集群

自从activemq5.9.0开始，activemq的集群实现方式取消了传统的Pure Master Slave方式，增加了基于zookeeper+leveldb的实现方式，其他两种方式：目录共享和数据库共享依然存在。

本文主要阐述基于zookeeper和leveldb搭建activemq集群，这里需要特别提醒，本文实现的集群仅提供主备功能，避免单点故障，没有负载均衡功能。

下面开始我们的征途。
一、搭建zookeeper集群

    关于搭建zookeeper集群的文章请参考：Zookeeper 集群搭建

    本文使用zookeeper3.4.6，3台虚拟机：192.168.2.161, 192.168.2.145, 192.168.2.146，zookeeper使用其默认端口：2181

二、搭建activemq集群

1、安装
    activemq本身的安装过程很简单，本文不详述，可参照官方的Getting-started

2、配置
    在三台机器上完成activemq安装之后，开始集群配置，通过配置使三个activemq实例组成集群。下面的配置在三个实例上保持一致，除了标红部分，主要修改配置文件conf/activemq.xml。

    （1）broker-name的统一
        将broker标签的brokerName属性设置为统一的值，我将这个值设置为“test”，只有三个实例的brokerName一致，zookeeper才能识别它们属于同一个集群

    （2）persistenceAdapter的配置
        persistenceAdapter设置持久化方式，主要有三种方式：kahaDB（默认方式）、数据库持久化、levelDB（v5.9.0提供支持）
        本文采用levelDB来进行持久化，并使用zookeeper实现集群的高可用，配置如下：
        首先注释掉原来kahaDB的持久化方式，然后配置levelDB+zookeeper的持久化方式。

<broker brokerName="test" ... >
...
<!--
<persistenceAdapter>
    <kahaDB directory="${activemq.data}/kahadb"/>
</persistenceAdapter>
-->
<persistenceAdapter>
    <replicatedLevelDB
      directory="${activemq.data}/leveldb"
      replicas="3"
      bind="tcp://0.0.0.0:0"
      zkAddress="192.168.2.161:2181,192.168.2.145:2181,192.168.2.146:2181"
      hostname="192.168.2.161"
      sync="local_disk"
      zkPath="/activemq/leveldb-stores"
      />
</persistenceAdapter>
...
</broker>

    注意:上述配置中的hostname属性值，不同的activemq实例对应不同的hostname值，其他两个实例配置的hostname值分别为：192.168.2.145, 192.168.2.146

3.如何工作

  他使用Apach Zookeeper去协调集群中的那个节点成为master.被选择为master的节点开始工作并接收客户端的连接。其他的节点进入slave模式并连接到master同步他们的持久状态。slave节点不接受客户端的连接。所有持久操作被复制到连接的slave节点上。如果master节点死了，带着最新更新数据的slave节点晋升为master节点。失败的节点然后能够回到在线并且他进入slave模式。

  如果master死了，得到了最新更新的slave被允许成为master。fialed node能够重新加入到网络中并连接master进入slave mode。所有需要同步到硬盘的消息的操作在他完成前将等待所有法定人数的节点复制完成。因此，如果你配置 replicas="3"，那么法定人数的值是(3/2+1=2)。master节点在他报告成功之前将在本地存储完最新的数据并等待1个其他slave节点存储完最新的数据。也就是，Master将会存储并更新然后等待 (2-1)=1个slave存储和更新完成，才汇报success。至于为什么是2-1，熟悉Zookeeper的应该知道，有一个node要作为观擦者存在。

  当一个新的master节点要被选择的时候，你也需要至少法定人数的节点在线为能够找到一个带着最新的更新数据的节点，那个带着最新的更新数据的节点将变成新的master。因此，建议你至少运行3个重复节点以至你能down掉一个节点不影响服务的输出。





4、测试

    测试目的：测试activemq的failover以及与zookeeper的整合

    测试原因：activemq有多种持久化模式，但是都可能存在单点故障的情况。与zookeeper整合后基本可以保证(n-1)/2的容错率。其中n表示服务器数量

    测试备注：该模式下还是单节点负载，只是由于引入了zookeeper的监测机制。保证多个activemq服务在同一时间内只有一个服务对外开放

    然后就开始http://192.168.2.161:8161 或者http://192.168.2.145:8161

或者http://192.168.2.146:8161

    这三个链接看哪个能访问，哪个消息服务器则表示存活提供服务

    这种配置方案能够实现(n-1)/2的容错率，也就是三台服务器允许挂一台，五个能当掉2个，依次类推

    客户端连接使用failover方案：

failover:(tcp://192.168.1.191:61616,tcp://192.168.1.192:61616,tcp://192.168.1.193:61616)?initialReconnectDelay=1000

    关掉其中任何一台，经过测试能够正常提供服务，客户端会自动切换连接，达到预期目的

5.参考

  http://activemq.apache.org/replicated-leveldb-store.html