ActiveMQ实现简单集群和HA

先作一个简单说明，我这个版本的ActiveMQ集群部署并不严谨，对于大型企业可能并不适用，若有意见或者建议欢迎留言交流。

1. 集群架构

** _一言不合就直接上架构图 _ **

1. 集群采用两台机器，四个实例部署，每台机器上各部署两个实例，一台为master，另外一台为slave。

2. HA实现：BrokerA和BrokerA-slave经过kahadb实现主备，哪一个先启动，哪一个就是master，另一个就是slave；当master挂了，slave自动升级为master，并对外提供服务。同理BrokerB和BrokerB-slave。
3. 集群实现须要多个条件，如集群是可负载均衡的、集群间的主机是能够相互通讯的、集群中一台主机挂了不会影响整个集群对外提供服务。
   3.1. 实现条件一：client端必须经过failover访问BrokerA和BrokerB。好比client发起100个请求，这100个请求会分摊在BrokerA和BrokerB上。
   3.2. 实现条件二：BrokerA须要经过网络桥接联通到BrokerB和BrokerB-slave，BrokerA-slave须要经过网络桥接联通BrokerB和BrokerB-slave。这样，BrokerA收到消息后，能够经过BrokerB去消费消息。BrokerB和BrokerB-slave同理。

如此，便基本实现了简单的集群和HA.

2. 集群配置

2.1 IP及端口规划

** 注**：admin端口为后台管理页面的端口，配置在jetty.xml中。

2.2 activemq.xml及jetty.xml配置

** jetty.xml就涉及到后台服务的端口修改，因此配置文件就很少作说明。**

• brokerA conf目录下的activemq.xml配置修改

/修改brokerName/ <broker xmlns="http://activemq.apache.org/schema/core" brokerName="BrokerA" dataDirectory="${activemq.data}"> /修改kahaDB路径/ <persistenceAdapter> <kahaDB directory="/home/dev/activeMQ/kahaDB"/> </persistenceAdapter> /修改网络桥接/ <networkConnectors> <networkConnector uri="static:(tcp://host2:61616,tcp://host2:61617)" duplex="true"/> </networkConnectors>

- brokerA-slave conf目录下的activemq.xml配置修改

    ```
/**修改brokerName**/
<broker xmlns="http://activemq.apache.org/schema/core" brokerName="BrokerA-slave" dataDirectory="${activemq.data}">
/**修改kahaDB路径**/
<persistenceAdapter>
	<kahaDB directory="/home/dev/activeMQ/kahaDB"/>
</persistenceAdapter>
/**修改网络桥接**/
<networkConnectors>
	<networkConnector uri="static:(tcp://host2:61616,tcp://host2:61617)" duplex="true"/>
</networkConnectors>

• brokerB conf目录下的activemq.xml配置修改

/修改brokerName/ <broker xmlns="http://activemq.apache.org/schema/core" brokerName="BrokerB" dataDirectory="${activemq.data}"> /修改kahaDB路径/ <persistenceAdapter> <kahaDB directory="/home/dev/activeMQ/kahaDB"/> </persistenceAdapter> /修改网络桥接/ <networkConnectors> <networkConnector uri="static:(tcp://host1:61616,tcp://host1:61617)" duplex="true"/> </networkConnectors>

- brokerB-slave conf目录下的activemq.xml配置修改

    ```
/**修改brokerName**/
<broker xmlns="http://activemq.apache.org/schema/core" brokerName="BrokerB-slave" dataDirectory="${activemq.data}">
/**修改kahaDB路径**/
<persistenceAdapter>
	<kahaDB directory="/home/dev/activeMQ/kahaDB"/>
</persistenceAdapter>
/**修改网络桥接**/
<networkConnectors>
	<networkConnector uri="static:(tcp://host1:61616,tcp://host1:61617)" duplex="true"/>
</networkConnectors>

3. 集群测试

固然，集群和HA要经得起考验，经过如下几个用例对其进行测试： ###3.1. 测试集群负载 ####3.1.1. 用例一

• 前置条件：BrokerA和BrokerB做为master对外提供服务
• 测试场景：producer经过failover向集群发起10次请求(发送消息),看请求如何分配
• 过程分析：经过failover进行client负载，能够将请求分摊到两个实例上
• 测试结果：略

####3.1.2. 用例二

• 前置条件：BrokerA和BrokerB做为master对外提供服务，两个实例都有未消费的消息
• 测试场景：consumer经过failover向集群发起消费消息请求，看请求如何分配
• 过程分析：经过failover进行client负载，能够将请求分摊到两个实例上
• 测试结果：略

###3.2. 测试集群HA ####3.2.1. 用例一

• 前置条件：BrokerA和BrokerB做为master对外提供服务
• 测试场景：将BrokerA kill掉，producer经过failover向集群发送10次请求，看请求会如何分配
• 过程分析：BrokerA挂了后，释放hakadb文件锁，BrokerA-slave得到文件锁，升级为master并对外提供服务；经过failover进行client负载，能够将请求分摊到两个实例上
• 测试结果：请求会分摊到BrokerA-slave和BrokerB两个实例上

####3.2.1. 用例二

• 前置条件：BrokerA和BrokerB做为master对外提供服务，而且BrokerA上面有还未消费的消息
• 测试场景：将BrokerA kill掉，consumer经过failover向集群发送消费消息请求
• 过程分析：BrokerA挂了后，未消费的消息持久化在hakadb中，BrokerA-slave升级为master对外提供服务，并加载未消息的消息，因此consumer请求消费消息的时候能够得到未消费的消息
• 测试结果：略

桥接方式的好处：

1. 当ActiveMQ面对大量消息存储和大量Client交互时，性能消耗将会达到单个broker极限，此时咱们须要对ActiveMQ进行水平扩展。ActiveMQ提供了“network”机制，能够把多个broker实例“串联”一块儿，造成“Forward Bridge”模型(转发桥)。这些Broker经过有向网络(networkerConnector)连接在一块儿，组成broker集群，任何一个Borker均可以与Client数据交互，消息也将在Broker网络中“流动”直到被消费，之因此“流动”，由于“producer”和“consumer”会与不一样的broker创建连接，咱们认为“转发桥”架构模式是“较大”集群数据的解决方案。

2. 在master-slave模式中，消息将会在多个broker上备份，即集群中每一个broker上消息都同样，在故障转移时不会发生消息丢失的问题(持久化消息)。“Forward Bridge”意味着消息能够在broker间“转发”直到消息被消费，在任意时刻一条消息只会被一个broker持有；Producer发送的消息，可能会通过多个Broker转发最终才会到达Consumer，若是其中某个Broker失效，那么其上的消息将不可用（固然也能够为每一个节点采用M-S架构，以提升可用性），直到它再次加入集群，所以“Forward Brige”模式并非ActiveMQ HA(高可用)方案,可是由于集群中每一个Broker均可以独立为Client服务并且消息能够动态的在网络中迁移，因此“Forward Bridge”是解决海量消息的必备策略。

ref：

http://shift-alt-ctrl.iteye.com/blog/2070531