首页 > Java开发 > ActiveMQ的集群与高可用

ActiveMQ的集群与高可用

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


本文固定链接: http://www.devba.com/index.php/archives/4100.html | 开发吧

报歉!评论已关闭.