ActiveMQ集群架构

几种典型架构分析

Posted by Cadmean on November 26, 2017

最近一直在研究ActiveMQ的集群功能,遍寻了很多资料,发现了不少有趣的知识。比如我们常常使用的是多个ActiveMQ Broker之间两两互联的方式,在图论中也叫完全图(complete graph)。可是ActiveMQ不仅仅只有完全图这种拓扑结构,今天介绍的就是其他几种有用的集群架构。

资料参考RedHat Fuse Esb Enterprise

1. 集线器拓扑(Concentrator Topology)

Concentrator Topology

适用场景:生产者或消费者端有大量连接,而另一端连接相对较少。

集线器拓扑可处理生产者和消费者两端连接数量相差较大的场景,相比完全图来说,集群的负载较低。第一层是多个互不相连的Broker,每个Broker都负责与大量的生产者(消费者)客户端进行连接。第二层是相对较少数量的Broker,负责与数量较少的消费者(生产者)客户端进行连接,且第二层的Broker与第一层的每一个Broker之间都建立连接。

这里说的集群负载,主要指的是由于消费者建立带来的Advisory Message风暴。

2. 星状拓扑(Hub and spokes topology)

Hub and Spoke Topology

适用场景:星状结构和集线器拓扑有点类似,都是适用于两端的客户端数量相差较大的场景。但是星状拓扑更易于维护。

星状拓扑中的H节点是最重要的节点,集群很容易因为H节点的宕机而导致失联。因此H节点需要有更高的配置。但是在拓展性上来说,如果需要拓展一个节点G,只需要在该节点上配置连接H节点,并设置duplux=true,H节点上无需做任何配置调整。也就是说在拓展性上便利到了极致。

3. 树形拓扑(Tree Topology)

Tree Topology

适用场景:适用于根据自然的环境限制(如火墙)来搭建这种拓扑结构。

每一个根节点都是关键节点,特别是R节点。因此这种拓扑的使用场景较少,我能想到的场景也就是网络线缆,火墙等因素所导致不得不使用这种拓扑架构。

4. 网格拓扑(Mesh Topology)

Mesh Topology

适用场景:适用于根据自然的环境限制(如火墙)来搭建这种拓扑结构。

相比树形结构,有较健壮的结构。但是每增加一个节点,都需要考虑集群转发节点数量的问题(networkTTL)。因此需要有一个机制在每增加一个节点的时候都需要调整相连节点的networkTTL。

5. 完全图(Complete Graph)

The Complete Graph, K5

适用场景:适用于能支持自发现Multicast Discovery的网络场景。

使用完全图的场景下,集群间的互动会比较复杂。比如在A上添加一个消费者,A会将Advisory Message发送给BCDE四个节点,而BCDE收到消息后,在自身上建立集群转发的消费者,而后又会广播一次Advisory Message给其他节点。假设集群中有N个Broker,那么一个新的消费者的建立就会导致集群产生N*(N-1)次消息处理。但如果后续有同个目的地的新消费者连接相同broker,那集群只会有(N-1)次消息处理。

结合集线器拓扑架构来看看集群负载的情况。若使用集线器拓扑,假设第一层M个Broker,第二层N个Broker,一个新的消费者连接第一层的任意一个broker,集群只会产生N+M次消息处理。后续有相同目的地的消费者连接相同broker,集群会有M次消息处理。

举个例子,如果使用完全图,8个节点的Broker,一个新的消费者建立会有56次消息处理,后续相同目的地的消费者连接相同mq则是7次消息处理。第一层8个节点,第2层2个节点的集线器拓扑,集群只有10次消息处理,后续相同目的地的消费者连接第一层相同mq只有2次消息处理。

当然,完全图的这种不足可以进一步通过修改源码中的advisory机制来实现,只需要在发送Advisory消息的时候,判断一下是否是集群转发的消费者(以brokername开头的consumerID,中间会有 -> 符号),而后不发送即可。


< script src = " / js / bootstrap.min.js " >