基于zookeeper+leveldb搭建activemq集群

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

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

下面开始咱们的征途。 
1、搭建zookeeper集群 

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

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

2、搭建activemq集群 

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

二、配置 
    在三台机器上完成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掉一个节点不影响服务的输出。 


 


四、测试 

    测试目的：测试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 

本文出自http://maosheng.iteye.com/blog/2224967