activeMQ使用总结 (集群方案)

1.   MQ现状

1.1. 概述

ActiveMQ 是Apache出品，最流行的，能力强劲的开源消息总线。彻底支持JMS1.1和J2EE 1.4规范的JMS Provider实现

1.2. activemq的特性

• 多种语言和协议编写客户端。语言: Java, C, C++, C#, Ruby, Perl, Python, PHP。应用协议: OpenWire,Stomp REST,WS Notification,XMPP,AMQP
• 彻底支持JMS1.1和J2EE 1.4规范 (持久化,XA消息,事务)
• 对Spring的支持,ActiveMQ能够很容易内嵌到使用Spring的系统里面去,并且也支持Spring2.0的特性
• 经过了常见J2EE服务器(如 Geronimo,JBoss 4, GlassFish,WebLogic)的测试,其中经过JCA 1.5 resourceadaptors的配置,可让ActiveMQ能够自动的部署到任何兼容J2EE1.4商业服务器上
• 支持多种传送协议:in-VM,TCP,SSL,NIO,UDP,JGroups,JXTA
• 支持经过JDBC和journal提供高速的消息持久化
• 从设计上保证了高性能的集群,客户端-服务器,点对点
• 支持Ajax
• 支持与Axis的整合
• 能够很容易得调用内嵌JMS provider,进行测试

1.3. 现有方案

利用官方提供的基于network的cluster方案。

1.4. 存在问题

基于cluster的方案，用的版本比较旧5.6，其network之间通道存在tcp半链接问题，致使集群频频出现问题。

目前是，直接采用一台MQ进行业务操做，按现有业务，能够支持现有的高并发。

实际上，目前迫切须要的是进行MQ的高可用，即Master-Slave方案

2.   MQ提供的集群方案

2.1. broker-cluster负载方案

Broker-Cluster的部署方式就能够解决负载均衡的问题。Broker-Cluster部署方式中，各个broker经过网络互相链接，并共享queue。当broker-A上面指定的queue-A中接收到一个message处于pending状态，而此时没有consumer链接broker-A时。若是cluster中的broker-B上面由一个consumer在消费queue-A的消息，那么broker-B会先经过内部网络获取到broker-A上面的message，并通知本身的consumer来消费。

2.1.1.   static Broker-Cluster部署

<networkConnectors> 

                <networkConnector   uri="static:(tcp:// 0.0.0.0:61617)"duplex="false"/>

</networkConnectors>

2.1.2.   Dynamic Broker-Cluster部署

<networkConnectors> 

           <networkConnectoruri="multicast://default"

           dynamicOnly="true"

           networkTTL="3"

           prefetchSize="1"

           decreaseNetworkConsumerPriority="true" />

</networkConnectors>

 

2.2. master-slave高可用方案

2.2.1.   shared filesystem Master-Slave部署方式

主要是经过共享存储目录来实现master和slave的热备，全部的ActiveMQ应用都在不断地获取共享目录的控制权，哪一个应用抢到了控制权，它就成为master。

多个共享存储目录的应用，谁先启动，谁就能够最先取得共享目录的控制权成为master，其余的应用就只能做为slave。

 

2.2.2.   shared database Master-Slave方式

与shared filesystem方式相似，只是共享的存储介质由文件系统改为了数据库而已。

2.2.3.   Replicated LevelDB Store方式

         这种主备方式是ActiveMQ5.9之后才新增的特性，使用ZooKeeper协调选择一个node做为master。被选择的master broker node开启并接受客户端链接。

其余node转入slave模式，链接master并同步他们的存储状态。slave不接受客户端链接。全部的存储操做都将被复制到链接至Master的slaves。

若是master死了，获得了最新更新的slave被容许成为master。fialed node可以从新加入到网络中并链接master进入slave mode。全部须要同步的disk的消息操做都将等待存储状态被复制到其余法定节点的操做完成才能完成。因此，若是你配置了replicas=3，那么法定大小是(3/2)+1=2. Master将会存储并更新而后等待 (2-1)=1个slave存储和更新完成，才汇报success。至于为何是2-1，熟悉Zookeeper的应该知道，有一个node要做为观擦者存在。

单一个新的master被选中，你须要至少保障一个法定node在线以可以找到拥有最新状态的node。这个node将会成为新的master。所以，推荐运行至少3个replica nodes，以防止一个node失败了，服务中断。

2.3. 方案对比

• broker-cluster的集群在多个broker之间fail-over和 load-balance
• master-slave能fail-over，可是不能load- balance
• 消息在多个broker之间转发，可是消息只存储在一个broker上，一旦失效必须重启，而主从方式master失效，slave实时备份消息。
• jdbc方式成本高，效率低
• master-slave方式中pure方式管理起来麻烦

所以，咱们把MASTER/SLAVE和BROKER CLUSTER二者相结合，能够获得一个彻底解决方案：即又能够作到集群又能够作到任何一个BROKER若是发生宕机节点消息也不丢失。

 

3.   最佳方案

3.1. 方案介绍

根据以上方案，结合优缺点，最终咱们须要实现集群的高可用和负载均衡，因此结合后，基于zookeeper+network的集群解决方案，具体以下图所示：

 

集群链接方式以下图：

 

3.2. 升级策略

针对如今线上使用MQ的现状分析，目前须要首先考虑支持高可用，因此以上方案可进行逐步实施：

1 对现有的MQ升级到最新版本，并测试验证对5.6的兼容性

2 搭建基于zookeeper的Master-Slave集群GA-MQ。

3 在高可用集群GA-MQ和原有MQ之间创建network链接。

4 切换线上生产者到新的集群GA-MQ

5 切换线上消费者到新的集群GA-MQ

6 等待原有MQ消息彻底处理完成后，关闭服务。

7 搭建GB-MQ集群，并按照业务进行负载划分。

8 在GA-MQ和GB-MQ之间创建network链接，实现最终方案。

 

以上每一步，都须要进行严格的测试验证，才可进行生产环境的切换。