ActiveMq+Zookeeper的高可用集群环境搭建_activemq zookeeper版本选择

一、简介

ActiveMq是由Apache旗下一款开源，流行且强悍的消息中间件。它是一个完全支持JMS1.1和J2EE 1.4规范的JMS Provider实现，ActiveMq非常快速并支持多种语言的客户端和协议，可以非常容易的嵌入到企业的应用环境中，并有许多高级功能。

之前公司有项目使用过ActiveMq，但由于之前对这个的使用范围不大也一直是单机环境，现在考虑搭一套集群环境避免因一些网络或其他原因引起的单点故障，从而造成主系统不可用。随后从官网了解到ActiveMq主从集群模式有三种，在同一时间内只有主Master能提供服务，其他从Slave节点则不可用，具体如下：

1、kahaDB：通过文件共享，在5.9之前的版本都是默认这个模式。

2、JDBC：通过数据库共享。

3、LevelDB：主从数据复制，5.9之后的版本官方都推荐这种方式，据说效率极高。

1/2都是一份存储共享，这份共享数据出问题就完蛋了，另外JDBC方式在大量的消息读写处理时效率是个问题，所有就优先选择LevelDB模式了，之后就需要有一个分布式的协调者ZooKeeper来协调、集成这些服务了。

Zookeeper作为Hadoop项目中的一个子项目,它主要用来解决分布式应用中经常遇到的数据管理问题，如集群管理、统一命名服务、分布式配置管理、分布式消息队列、分布式锁、分布式协调等，它可以用来简化分布式应用协调及其管理的难度，保证数据在ZK集群之间的数据的事务性一致，提供高性能且准确的分布式协调服务。

LevelDB模式使用ZooKeeper的机制进行Master的选举，Master节点的选择需要获得超过一半及以上节点的同意，所以参与选举的节点必须要在三个及以上，在选举期间没有选中的Slave节点会与Master保持通讯实时接受Master节点中操作成功的数据。另外根据的规则ZooKeeper运行是否正常也至少需要超过一半节点的同意，如有3个节点，其中2个节点正常ZooKeeper就正常，在这种机制下建4个节点的效果和3个是一致的，所以我们通常会安装2N-1个节点。

二、版本选择

• ActiveMq ：ActiveMq版本的选择与JDK有关，下表列出一个依赖关系，大家可以根据自己的实际情况来选择合适的版本。

我这边由于客户提供的服务器的JDK基本上都是1.7的，又考虑7的小版本也有可能参差不齐就选择5.11.0了，保证向上兼容是1.7就行。（一开始我选择的是5.10.2，但装上去跑的时候出问题，最后一看才发现这个版本有BUG。。。）

• Zookeeper ：Zookeeper的版本就没什么要求了，选择的是3.4.9，保证最新的稳定版就行了。

二、下载安装

准备mq和zk的安装介质，想直接使用apache-activemq-5.12.0、zookeeper-3.4.9和Jdk1.7.0_80可以直接到我的百度网盘下载：http://pan.baidu.com/s/1qXNbfTM i6bt
当然也可以直接去官网：ActiveMq Zookeeper
将mq和zk的tar包传到服务器上并用tar -zxvf命令解压并指定到安装目录，我这边有准备了3台机器，地址分别是172.16.85.3，172.16.85.4，172.16.85.5（也可以一台上装多个实例），每台机器上都要重复一次。

三、配置

先配置Zookeeper部分，再配置ActiveMq

1、Zookeeper

首先在安装的根目录下新增两个文件夹data和logs，用来存数据和日志信息。

mkdir data
mkdir logs
1
2

• zoo.cfg文件配置：
  在安装根的conf目录下将zoo_sample.cfg文件复制一份，并重命名为zoo.cfg，将在文件的最后增加如下代码：

dataDir=/opt/activemq-cluster/zookeeper-3.4.9/data
dataLogDir=/opt/activemq-cluster/zookeeper-3.4.9/logs
1
2

server.1： 表示当前服务的序号，数字与myid文件值对应（后面配置）
172.16.84.5： 服务器地址
2888： 集群成员信息交换端口
3888： 是Leader挂掉后用来选举Leader的端口

server.1=172.16.85.3:2888:3888
server.2=172.16.85.4:2888:3888
server.3=172.16.85.5:2888:3888
1
2
3

• myid文件配置：
  在/zookeeper-3.4.9/data中创建myid文件并根据节点数输入对应值，在主机上执行如下命令：

echo "1" > myid
echo "2" > myid
echo "3" > myid
1
2
3

上面的示例配置是一台主机的，若有3台就需要重复3次配置。另外如果想用一台服务器安装3个实例来做集群可以调整以下配置的端口：
1、zoo.cfg文件中clientPort的配置，每个实例可以依次为2181，2182,2183，
2、zoo.cfg文件中server的配置，每个实例可以依次为：
server.1=172.16.85.3:2888:3888
server.2=172.16.85.3:2889:3889
server.3=172.16.85.3:2890:3890
3、myid文件就和上面一个主机一个实例的一样了，每个实例下都对应生产myid

• 启动ZK：

cd到/zookeeper-3.4.9/bin目录，执行启动命令。

./zkServer.sh start
1

建议启动的同时到当前目录的zookeeper.out文件中查看下启动日志，看看是否有问题，方便对应解决。

tail -f zookeeper.out
1

若启动成功可以使用下面的命令来查看当前节点是否是主节点，Master为主，follower为从。

./zkServer.sh status
1

2、ActiveMq

• 文件配置：

  cd到安装根下的config目录如：/apache-activemq-5.11.0/conf，找到activemq.xml文件，修改里面的persistenceAdapter元素的内容，并指定LevelDB模式。
  修改前：

<persistenceAdapter>
    <kahaDB directory="${activemq.data}/kahadb"/>
</persistenceAdapter>
1
2
3

修改后：

<persistenceAdapter>
    <replicatedLevelDB  
       directory="${activemq.data}/leveldb"
        replicas="3"
        bind="tcp://0.0.0.0:0"
        zkAddress="172.16.85.3:2181,172.16.85.4:2181,172.16.85.5:2181"
        hostname="172.16.85.3"
        zkPath="/activemq/leveldb-stores" sync="local_disk"/>
</persistenceAdapter>
1
2
3
4
5
6
7
8
9

其中，
directory：使用默认目录，不用调整。
replicas：是集群几点数，我这里是三台主机，一台一个实例，所以是3个。
bind：当这个节点成为主节点后，就会默认绑定当前IP和端口，不用调整。
zkAddress：3台zookeeper的服务IP和端口，用逗号隔开。若是一台多个实例这里IP不变，端口要跟着变。
hostname：填写当前主机的IP地址。
zkPath：使用默认路径，不用调整。

另外，若是一个主机3个实例，还需要手动调整MQ默认的服务端口61616和管理控制台8161端口。
服务端口在activemq.xml中，这一行中的端口应分别为61616，61617，61618

管理控制台端口在同目录的jetty.xml中，这一行中的端口应分别为8161,8162,8163

• 启动MQ：
  cd到bin目录，如：/opt/activeMq/apache-activemq-5.11.0/bin/linux-x86-64

./activemq start
1

同时到当前安装根的data目录文件activemq.log中查看下启动日志，看看是否有问题，方便对应解决
/opt/activeMq/apache-activemq-5.11.0/data

tail -f activemq.log
1

四、访问验证

zk和mq都成功启动后，可以在后台执行netstat -an |grep 61616 来查看端口有没有被监听，然后访问MQ控制台来查看，正常情况下三台只有Master节点可以访问到，其余为等待状态服务不可用。若将其中一台MQ的master节点kill掉，会发现剩余两个从节点的其中一个会成功主节点。
http://172.16.85.3:8161/admin/queues.jsp
http://172.16.85.4:8161/admin/queues.jsp
http://172.16.85.5:8161/admin/queues.jsp
一台3个实例则为：
http://172.16.85.3:8161/admin/queues.jsp
http://172.16.85.3:8162/admin/queues.jsp
http://172.16.85.3:8163/admin/queues.jsp

最后是使用客户端进行连接，使用failover的主备救援方式来保证与Master节点的通讯。

jms.brokerURL=failover://(tcp://172.16.85.3:61616,tcp://172.16.85.4:61616,tcp://172.16.85.5:61616)?initialReconnectDelay=1000&timeout=3000
1

一台三个实例则为：

jms.brokerURL=failover://(tcp://172.16.85.3:61616,tcp://172.16.85.3:61617,tcp://172.16.85.3:61618)?initialReconnectDelay=1000&timeout=3000
1

另外具体客户端java代码的集成访问，见 http://blog.csdn.net/lance_zy/article/details/78403251。