ActiveMQ实现简单集群和HA
2016-07-22 00:00
405 查看
摘要: 集群有四个ActiveMQ实例组成,通过client的failover机制、broker集群、broker之间的网络桥接通信、master-slave通过共享文件机制实现消息队列集群的集群负载和HA。
先做一个简单说明,我这个版本的ActiveMQ集群部署并不严谨,对于大型企业可能并不适用,如有意见或者建议欢迎留言交流。
_一言不合就直接上架构图 _
**
集群采用两台机器,四个实例部署,每台机器上各部署两个实例,一台为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.
** 注**:admin端口为后台管理页面的端口,配置在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>
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>
###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
先做一个简单说明,我这个版本的ActiveMQ集群部署并不严谨,对于大型企业可能并不适用,如有意见或者建议欢迎留言交流。
1. 集群架构
**_一言不合就直接上架构图 _
**
集群采用两台机器,四个实例部署,每台机器上各部署两个实例,一台为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
相关文章推荐
- mongo实现消息队列
- RedHat 5.8 安装Oracle 11gR2_Grid集群
- Rabbitmq集群搭建笔记
- mysql集群之MMM简单搭建
- SQL Server高可用的常见问题分析
- MySQL的集群配置的基本命令使用及一次操作过程实录
- 进程间通信之深入消息队列的详解
- MySQL slave_net_timeout参数解决的一个集群问题案例
- 解析ActiveMQ的使用说明总结
- ActiveMQ在C#中的应用示例分析
- Redis 集群搭建和简单使用教程
- Windows Server 2003 下配置 MySQL 集群(Cluster)教程
- tomcat6_apache2.2_ajp 负载均衡加集群实战分享
- windows NLB+ARR实现Web负载均衡高可用/可伸缩的方法
- 基于条件变量的消息队列 说明介绍
- MySQL数据库的高可用方案总结
- PHP消息队列用法实例分析
- PHP使用php-resque库配合Redis实现MQ消息队列的教程
- PHP+memcache实现消息队列案例分享