ActiveMQ实现简单集群和HA

最新推荐文章于 2024-01-23 01:28:46 发布

weixin_34044273

最新推荐文章于 2024-01-23 01:28:46 发布

阅读量131

点赞数

文章标签：网络 python

原文链接：https://my.oschina.net/hzchenyh/blog/716424

版权

2019独角兽企业重金招聘Python工程师标准>>>

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

1. 集群架构

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

ActiveMQ集群+HA

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

HA实现：BrokerA和BrokerA-slave通过kahadb实现主备，哪个先启动，哪个就是master，另外一个就是slave；当master挂了，slave自动升级为master，并对外提供服务。同理BrokerB和BrokerB-slave。
集群实现需要多个条件，如集群是可负载均衡的、集群间的主机是可以相互通信的、集群中一台主机挂了不会影响整个集群对外提供服务。
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请求消费消息的时候可以获得未消费的消息
测试结果：略

桥接方式的好处：

当ActiveMQ面对大量消息存储和大量Client交互时，性能消耗将会达到单个broker极限，此时我们需要对ActiveMQ进行水平扩展。ActiveMQ提供了“network”机制，可以把多个broker实例“串联”一起，形成“Forward Bridge”模型(转发桥)。这些Broker通过有向网络(networkerConnector)链接在一起，组成broker集群，任何一个Borker都可以与Client数据交互，消息也将在Broker网络中“流动”直到被消费，之所以“流动”，因为“producer”和“consumer”会与不同的broker建立链接，我们认为“转发桥”架构模式是“较大”集群数据的解决方案。
在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

转载于:https://my.oschina.net/hzchenyh/blog/716424