概述
在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、总之,对于异步通信而言,我们通常允许消息积压,但不允许消息丢失,而网络又是不可靠的,所以一般不用这种模式。