ActiveMQ集群之Master-Slave

Activemq默认主要使用2个端口，8161(Web管理控制台端口）、61616（提供消息队列服务的端口）

ActiveMQ具有强大和灵活的集群功能，但在使用的过程中会发现很多的缺点，ActiveMQ的集群方式主要由两种：Master-Slave和Broker Cluster。

1、Master-Slave

Master-Slave方式中，只能是Master提供服务，Slave是实时地备份Master的数据，以保证消息的可靠性。当Master失效时，Slave会自动升级为Master，客户端会自动连接到Slave上工作。Master-Slave模式分为三类：Pure Master Slave、Shared File System Master Slave和JDBC Master Slave。

 

消息持久性对于可靠消息传递来说应该是一种比较好的方法，有了消息持久化，即使发送者和接受者不是同时在线或者消息中心在发送者发送消息后宕机了，在消息中心重新启动后仍然可以将消息发送出去，如果把这种持久化和ReliableMessaging结合起来应该是很好的保证了消息的可靠传送。

 

消息持久性的原理很简单，就是在发送者将消息发送出去后，消息中心首先将消息存储到本地数据文件、内存数据库或者远程数据库等，然后试图将消息发送给接收者，发送成功则将消息从存储中删除，失败则继续尝试。消息中心启动以后首先要检查制定的存储位置，如果有未发送成功的消息，则需要把消息发送出去。

 

ActiveMQ持久化方式：AMQ、KahaDB、JDBC、LevelDB。

 

1.1、Pure Master Slave

Pure Master Slave具有以下限制：只能有一个slave broker连接到master broker。在因master broker失效后slave才接管（保证消息完全拷贝）要想恢复master，停止slave，拷贝slave中的数据文件到master中，然后重启。5.8版本之后已经不支持，了解可参考：http://activemq.apache.org/pure-master-slave.html

 

1.2、Shared File System Master

通过共享存储的方式实现主从架构，与Pure Master Slave不同在于可以有多个Slave。基本上，你可以运行多个broker，这些 broker 共享activemq数据目录。当第一个broker得到文件上的排他锁之后，其它的 broker 便会在循环中等待获得这把锁。默认每10秒判断一次。客户端使用failover transport来连接到可用的master broker。当master broker失效的时候会释放这把锁，这时候其中一个slave broker会得到这把锁从而成为 master broker。如果多套AMQ部署在不同的设备上，这里的directory应该指向一个远程的系统目录（分布式文件系统，NFS）。客户端通过failover方式进行连接，多个AMQ实例地址使用英文逗号隔开，当某个实例断开时会自动重连，但如果所有实例都失效，failover默认情况下会无限期的等待下去，不会有任何提示。

 

1.2.1、AMQ

AMQ是一种文件存储形式，它具有写入速度快和容易恢复的特点。消息存储在一个个文件中，文件的默认大小为32M，如果一条消息的大小超过了 32M，那么这个值必须设置大一点。当一个存储文件中的消息已经全部被消费，那么这个文件将被标识为可删除，在下一个清除阶段，这个文件被删除。AMQ适用于ActiveMQ5.3之前的版本。默认配置如下：

   

 

1.2.2、KahaDB

KahaDB是基于文件的本地数据库储存形式，虽然没有AMQ的速度快，但是它具有强扩展性，恢复的时间比AMQ短，从5.4版本之后KahaDB做为默认的持久化方式。

 

注意事项：

a、slave的控制台不能访问，原因就是slave没有拿到文件锁，不能访问文件。

b、master和slave设置的连接密码必须一致方便客户端连接

 

1.2.3、LevelDB

这种文件系统是从ActiveMQ5.8之后引进的，它和KahaDB非常相似，也是基于文件的本地数据库储存形式，但是它提供比KahaDB更快的持久性。与KahaDB不同的是，它不是使用传统的B-树来实现对日志数据的提前写，而是使用基于索引的LevelDB。

 

注意事项：

a、至少必须有3个节点

b、多个节点brokerName必须一致

 

1.3、JDBC Master Slave

可以将消息存储到数据库中，例如：Mysql、SQL Server、Oracle、DB2。

activemq.xml配置修改：

 

activemq.xml配置新增：

 

从配置中可以看出数据库的名称是testmq，你需要手动在MySql中增加这个库。然后重新启动消息队列，你会发现多了3张表：activemq_acks、activemq_lock、activemq_msgs

注意事项：

1、必须在activemq的lib目录下加入相关驱动包：mysql-connector-java-5.0.8.jar、commons-dbcp-1.2.2.jar、commons-pool-1.3.jar

2、必须手动创建数据库（testmq），并且数据库的字符集为：character-set改成latin1

3、可以持久化延迟的消息

4、可以打开slave的管控台

5、createTablesOnStartup=true待首次自动创建好表结构后，可修改其为false，提升效率

6、跟共享文件系统的方式类似，但是更可靠，速度上最慢

7、建议使用Mysql5.3以上版本（部分低版本锁有问题）

 

1.4、zookeeper Master Slave

注意事项：

1、replicated LevelDB 不支持延迟或者计划任务消息。这 些消息存储在另外的LevelDB文件中，如果使用延迟或者计划任务消息，将不会复制到Slave Broker上，不能实现消息的高可用。

2、每个 ActiveMQ 的 BrokerName 必须相同，否则不能加入集群。

配置说明：

a、这个zkPath代表zookeeper内的”路径”，即你运行在3181端口的zk内的”寻址节点”，类似于JNDI。如果你没有这个zkPath，默认它在zk内的寻址节点为”/default”。加入到某一组master slave中的mq的实例中的zkPath必须完全匹配。

b、replicas=”3”的设置 ，这边的数字指的就是ActiveMQ实例的节点数，它需要满足2N+1