介绍

当应用规模日渐增长时，2节点的broker可能仍然抗不住访问压力，这时候就需要多加一些broker，弄一个更大规模的Broker集群，但是怎么合理设置broker之间的网络桥接，却是有讲究的，先来看一种不太好的设计：

这个架构看上去没瑕疵，没毛病，3个broker之间两两互通，整体可用性极高，但是从消息的路由角度来看，却不是一个好的设计，当producer向broker1发送一条消息时，Consumer得到消息的路径可能有如下2条：

a） producer -> broker1 -> broker2

b） producer -> broker1 -> broker3 -> broker2

当broker更多时，情况会更复杂，比如下面这张图：

消息的路由途径将会更多：

a) producer -> broker1 -> broker4

b) producer -> broker1 -> broker2 -> broker4

c) producer -> broker1 -> broker2 -> broker3 -> broker4

d) producer -> broker1 -> broker3 -> broker4

不难想像，每多经过一个节点，消息处理的延时将会增加一些，如果Broker越多，情况越复杂，最终系统对外表现为消息处理有时很快，有时很慢，整体性能很不稳定，所以实际生产中，不要采用所有Broker之间两两互连的方案。

合理的方案如下：

这张图的灵感，应该来自组建局域网中的星形网络，在中心放置一个Borker充当Hub，与其它所有Broker互连，这样不管Consumer连接到外围的哪个Broker，消息的路由途径都比较稳定(最多经过3个Broker)，这种架构性能虽然稳定了，但是中心的Hub就变成单点隐患，如果中间的DockerHub挂了，整个系统也就废了。

改进后的架构如下：

本质上仍然是一个星形网络，只不过将hub弄成二个互备，然后每个hub都与其它外围的broker相连，消费者连接到broker1/broker2/broker3，生产者(Producer)连接到hub1/hub2，消息的最长路径不超过3个broker (注：生产者也可以连接到broker1/2/3，与消费者一样，但是消息经过的最长路径会变成4)
如果以后要扩张，比如增加了Broker4,Broker5…，直接修改hub1/2上的配置，增加与新的broker的连接即可，不影响消息的路由途径长度。

开始配置

1、端口规划
AMQ1:172.169.21.101:61616(broker1)
AMQ2:172.169.21.101:61626(broker2)
AMQ3:172.169.21.102:61616(broker3)
AMQ4:172.169.21.102:61626(broker4)
AMQ5:172.169.21.101:61645(hub1)
AMQ6:172.169.21.102:61645(hub2)
2、activemq.xml配置
以boker1为例，配置文件内容如下：

#修改brokerName,每台不一样

#修改消息端口为61616

broker2及broker3、broker4，参考该配置修改端口号及brokerName即可。
以hub1的配置：

#修改brokerName,每台不一样

#配置netwokeconnectors(需包含所有的bbroker节点)



#修改消息端口为61645

注意：如果有producer把消息发到（hub1）,则从其它所有节点上也能消费这条消息。

hub2参考该配置修改端口号及brokerName即可.

注意：

1、这种模式并不会起到负载均衡的作用，需要在客户端侧做负载均衡
2、项目通过failover进行调用
3、生产者通过HUB调用，消费者通过broker调用