這個架構看上去沒瑕疵，沒毛病，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、端口規劃
共5個activemq執行個體，端口61616、61626、61636為broker1、broker2、broker3，61645、61656為broker-hub1、broker-hub2
2、activemq.xml配置
以boker1為例，配置檔案内容如下：
View Code
broker2及broker3，大家參考該配置修改端口号及brokerName即可。
broker-hub1的配置：
broker-hub2的配置：
3、java代碼中spring配置檔案
a) 生産者
b) 消費者
參考文章：
<a href="http://www.jakubkorab.net/2011/11/understanding-activemq-broker-networks.html" target="_blank">http://www.jakubkorab.net/2011/11/understanding-activemq-broker-networks.html</a>