概述
在ActiveMQ运行过程中，如果发生某个queue只有生产者没有消费者的情况时，消息就会产生积压。Network of brokers模式通过将积压的消息转发给处于同一network的其它broker的方式很好地解决了这个问题，但这个模式也有问题。
基本配置
vim conf/activemq.xml
<broker>
....
<networkConnectors>
<networkConnector uri="static:(tcp://localhost:20001,tcp://localhost:20010,tcp://172.16.1.14:20001,tcp://172.16.1.14:20002,tcp://172.16.1.14:20003,tcp://172.16.1.14:20004)"/>
</networkConnectors>
<persistenceAdapter>
<kahaDB directory="${activemq.data}/kahadb"/>
....
</broker>
注：
1、<networkConnector uri="static:(....)">，括号中的实例要包括自己。可以理解为这些实例组成了一个网络，相互可以进行消息接收，但是只有做了这项配置的broker才能够将消息转发给网络中的其它broker。
2、activemq create /path/<broker_name>，注意network中的broker_name不能相同，相同则只有一个被本地broker当作消费者。
控制台展示
注：
1、标1的是真实消费者，一般由应用程序产生，标2的是网络中的其它broker，本地broker将消息转发给它们。
2、可以看出，本地broker将network中的其它broker和APPConsumer都当做是自己的消费者，平均分发消息。
3、本人猜想，这种模式实际上会增加broker的I/O消耗，因为同一条消息被接收和发送了两次。
4、broker通常用于异步通信，消息的即时性没那么强，实际生产中即使消费者宕了，我们只需通知让租户重启消费者即可，不必急于将消息分发出去。
5、这种模式并不会起到负载均衡的作用，因为发送给其它broker也消耗网络IO，反而加重了负载。通常直接在客户端侧做负载均衡更加方便。
6、network of brokers模式默认是单向的，即开通该功能的broker不会再接收消息，这意味着只有部分broker能够开启这个功能，而且会加重剩余broker的负载。
7、当集群规模较大时，这种方式还会使得生产者和消费者关系紊乱，不利于追踪消息的走向。对于消息中间件的部署，个人以为，简单即正义。
8、总之，对于异步通信而言，我们通常允许消息积压，但不允许消息丢失，而网络又是不可靠的，所以一般不用这种模式。