ActiveMQ的集群与高可用

标签: activemq 集群 | 发表时间:2013-10-31 19:59 | 作者:KimmKing
出处:http://blog.csdn.net

ActiveMQ的集群与高可用

针对大量的消息吞吐量、对MQ可用性要求非常严格的场景、或者非常复杂的消息处理关系情况下,单个MQ实例通常已经无法满足我们的需要,这时候ActiveMQ的集群和高可用方案就对我们很重要了。

1.client的集群

对消费者来说,使用queue即可做到某种意义上的消费者集群,所有消费者共同处理同一类消息。

非持久订阅的topic,这种功能没有实现。但是持久订阅的topic,可以通过Composite Destination机制转换成针对具体的持久消费者的专用queue,从而实现多个client共同处理同一类消息。参见: http://blog.csdn.net/kimmking/article/details/9773085 

需要注意的是,如果缓存了consumer(例如spring DMLC+cache consumer)情况下使用了prefetch,多个consumer间可能导致消息顺序混乱。见: http://activemq.apache.org/what-is-the-prefetch-limit-for.html

2.client的高可用

在客户端来说,最简单的高可用方案就是内置的failover机制。它帮助我们在客户端实现:

  • 在某个broker故障时,自动使用其他备用broker
  • 强大的断线重连机制,哪怕是只有一个broker时,也可以用来在broker down掉重启后,客户端重新连接上

断线重连的配置和参数说明参见: http://activemq.apache.org/failover-transport-reference.html

3.broker的集群

broker端,典型的集群方式就是Network Connector,通过桥接的方式把多个broker,一个个的串起来,整个broker网络就可以作为一个整体,协同工作。

每个connect上去的broker,都会自动在被连接的broker上创建一个client connecttion,并通过Advisory机制共享自己的消费者列表,从而使得消息可以跨过broker在这个网络上自由流动。也可以设置duplex为true使得这个连通变为双向的对等网络。在BrokerA上配置一个指向BrokerB上的network connector,则连接到BrokerA上的各个ConsumerA1、ConsumerA2、ConsumerA3,都可以消费BrokerB上的QueueB里的消息。默认这三个消费者都被当做一个消费者来看待,即如果BrokerB上有一个ConsumerB1消费。

详细参见: http://blog.csdn.net/kimmking/article/details/8440150 

其实个人感觉更好的集群方式是增加类似kafka和metaq的partition,然后使用zk作为配置中心来协调各个不同的broker实例、以及不同的partition来协同工作,使得broker的读写都可以分散进行。

4.broker的高可用

Broker端的高可用主要是Master-Slave实现的冷备,需要结合客户端的failover来用。

5.8.0以前的版本,支持三种Master-Slave:

  1. 基于共享储存的Master-Slave:多个broker实例使用一个存储文件,谁拿到文件锁就是master,其他处于待启动状态,如果master挂掉了,某个抢到文件锁的slave变成master。由于使用的还是master的存储文件,所以数据好似一致的。
  2. 基于JDBC的Master-Slave:使用同一个数据库,拿到LOCK表的写锁的broker成为master,机制同上。
  3. Pure Master-Slave:Slave的broker,简单的从Master复制数据和状态,问题较多,已被废弃。

5.9.0版本以后,Pure Master-Slave机制被废弃,新添加了基于zk的复制LevelDB存储Master-Slave机制。

此外还有一种可选方式就是,使用某种存储复制技术,比如Raid、或是DB的replication等等机制来同步存储,在故障的时候,使用这个复制的存储恢复broker。

详细参见: http://activemq.apache.org/masterslave.html 


作者:KimmKing 发表于2013-10-31 11:59:09 原文链接
阅读:76 评论:0 查看评论

相关 [activemq 集群] 推荐:

ActiveMQ的集群与高可用

- - CSDN博客架构设计推荐文章
ActiveMQ的集群与高可用. 针对大量的消息吞吐量、对MQ可用性要求非常严格的场景、或者非常复杂的消息处理关系情况下,单个MQ实例通常已经无法满足我们的需要,这时候ActiveMQ的集群和高可用方案就对我们很重要了. 对消费者来说,使用queue即可做到某种意义上的消费者集群,所有消费者共同处理同一类消息.

【ActiveMQ Tuning】Prefetch Limit

- - 博客园_首页
   摘要:ActiveMQ优化 客户端优化 预取限制. 原文: http://fusesource.com/docs/broker/5.4/tuning/GenTuning-Consumer-Prefetch.html. Overview:图列4.1阐明了Broker在等待之前发送给客户端消息的反馈的行为.

【ActiveMQ Tuning】Serializing to Disk

- - 博客园_首页
     翻译自: http://fusesource.com/docs/broker/5.4/tuning/PersTuning-SerialToDisk.html.      KahaDB message store:KahaDB 是ActiveMQ Broker 为了高性能而推荐使用的消息存储机制.

ActiveMQ 桥接

- - CSDN博客互联网推荐文章
使用目的:将本地产生的消息转发到远程,通过远程服务器来处理消息,处理完成后,再启动消费者处理本地服务器消息(验证消息是否被转走,本地无消息可处理为正常). 消息在下面的地址被消费,无需任何特别配置,采用默认的配置即可. 生产消息地址为localhost:7001,需要做如下配置. 注意: 表示只有这个队列的会进行桥接转发.

ActiveMQ学习小结

- - CSDN博客架构设计推荐文章
   Activemq是众多开源消息中间件的一种,支持集群,同等网络,自动检测,TCP,SSL,广播,持久化,和J2EE1.4容器无缝结合. 它是apache基金会的一个项目,而且经过多年发展,有了很高的稳定性. 目前被很多知名项目使用,比如Apache serviceMix、FuseESB.  消息中间件一般被用在异步消息通信、整合多个系统的场景,比如你注册CSDN论坛,你填写完注册信息点提交时,它会发一份验证邮箱的验证邮件给到你,这封邮件就可以通过消息中间异步发送给你.

ActiveMQ与Spring整合

- - 博客园_首页
ActiveMQ 是Apache出品, 是最流行​​和最强大的开源消息总线. 同时完全支持 JMS 1.1和J2EE 1.4规范. 支持多种编程语言和协议编写客户端. 在JMS客户端和消息代理完全支持企业集成模式. 完全支持JMS1.1和J2EE 1.4规范 (持久化,XA消息,事务). 对Spring的支持, ActiveMQ可以很容易内嵌到使用Spring的系统里面去,而且也支持Spring2.0的特性.

ActiveMQ高级特性

- - zzm
消息生产者使用持久(persistent)传递模式发送消息的时候,Producer.send() 方法会被阻塞,直到 broker 发送一个确认消息给生产者,这个确认消息暗示生产者 broker 已经成功地将它发送的消息路由到目标目的并把消息保存到二级存储中. 但有一个例外,当发送方法在一个事物上下文中时,被阻塞的是commit 方法而不是 send 方法.

ActiveMQ持久化方式

- - CSDN博客架构设计推荐文章
消息持久性对于可靠消息传递来说应该是一种比较好的方法,有了消息持久化,即使发送者和接受者不是同时在线或者消息中心在发送者发送消息后宕机了,在消息中心重新启动后仍然可以将消息发送出去,如果把这种持久化和ReliableMessaging结合起来应该是很好的保证了消息的可靠传送. 消息持久性的原理很简单,就是在发送者将消息发送出去后,消息中心首先将消息存储到本地数据文件、内存数据库或者远程数据库等,然后试图将消息发送给接收者,发送成功则将消息从存储中删除,失败则继续尝试.

[MQ]关于ActiveMQ的配置

- - 企业架构 - ITeye博客
  目前常用的消息队列组建无非就是MSMQ和ActiveMQ,至于他们的异同,这里不想做过多的比较. 简单来说,MSMQ内置于微软操作系统之中,在部署上包含一个隐性条件:Server需要是微软操作系统. (对于这点我并去调研过MSMQ是否可以部署在非微软系统,比如:Linux,只是拍脑袋想了想,感觉上是不可以).

优化ActiveMQ性能(zhuan)

- - zzm
1.  优化ActiveMQ性能. 1.PERSISTENT(持久性消息). 这是 ActiveMQ 的默认传送模式,此模式保证这些消息只被传送一次和成功使用一次. 对于这些消息,可靠性是优先考虑的因素. 可靠性的另一个重要方面是确保持久性消息传送至目标后,消息服务在向消费者传送它们之前不会丢失这些消息.