ActiveMQ集群配置详解

资料来源

1. ActiveMQ分布式网络(Forward Bridge)
2. Network of broker

项目里大量用到了ActiveMQ集群配置，根据官网和网络上资料的说法：当ActiveMQ面对大量消息存储和大量Client交互时，性能消耗将会达到单个broker极限，此时我们需要对ActiveMQ进行水平扩展。ActiveMQ提供了“network”机制，可以把多个broker实例“串联”一起，形成“Forward Bridge”模型(转发桥)。这些Broker通过有向网络(networkerConnector)链接在一起，组成broker集群，任何一个Borker都可以与Client数据交互，消息也将在Broker网络中“流动”直到被消费，之所以“流动”，因为“producer”和“consumer”会与不同的broker建立链接，我们认为“转发桥”架构模式是“较大”集群数据的解决方案。

我们使用了非持久化订阅，可是在实际使用中却发现有时候出现了丢消息的情况，也就是生产者将消息发送到Broker A，消费者连接Broker B，可是A并没有将消息转发给B。

下午仔细看了看ActiveMQ的集群配置，希望可以找到解决方法。先整理一下关于集群的配置吧。项目中用到的配置为

可支持的配置有：

1. dynamicOnly：用来表明connector是否只支持动态激活“durable订阅者”，默认为false，表示networkConnector在创建成功后，将立即激活所有的“durable Topic”，即使本地没有Topic的消费者(如果本地Broker已经有消费者，肯定会激活)，本地Broker也会创建一个“典型的”订阅者，并将订阅信息发送给remote Broker，此后remote Broker接收到的Topic消息也将转发给本地Broker。如果为true，那么netwokrConnector将不会立即激活它们(本地没有消费者的durable Topic)，直到从“Advisory”通知获取到激活消息(有Durable Consumer创建)时，才会做上述操作。它将对Durable Topic中消息在网络中转发的时机有重要影响。通常设定为false，以避免broker大面积失效时，Client迁移到那些尚没有接收到任何“Advisory”的新Broker节点上；不过如果网络比较稳定，设定dymanicOnly为true，可以有效的提升Topic消息的转发效率。该配置应该对持久化订阅生效，项目里不涉及。

2. decreaseNetworkConsumerPriority：是否降低网络消费者(Queue)的权重，默认为false，即remote Broker中的Consumers与本地Consumer具有相同的权重(默认值=0，我们可以为每个消费者指定权重)，消费者“权重”决定了它获取消息的优先级，较高权重的消费者将优先消费消息。如果此值为true，那么remote Broker中的Consumer将具有最低的优先级(-7),那么只有当Queue在Local Broker中没有Consumer，或者所有的Consumers都满负荷(prefetch Buffe已满)时，才会将消息转发给remote Broker中的Consumer。这是一种较好的调优策略，不仅可以降低消息转发的开支，而且还能较好的确保消息顺序，通常我们设置为true，唯一的缺点就是不利于Queue consumers在全局范围内负载均衡。 （这个配置可以解决的问题：首先保证消息被当前broker上的consumer消费，只有当本地所有的消费者都繁忙时才转发给remote broker上的consumer。）
   可考虑配置一下试试

3. networkTTL：消息和订阅在网络中转发的最大生命周期，默认为1，即消息只会在网络中转发一次，订阅也只会在网络中传播一次。消息在网络中每转发一次，都会将TTL-1，并且将当前的brokerId添加到路由信息中，当TTL=0或者当前brokerId已经在路由表中(此broker已经转发过此消息，避免loop)，那么消息将不会继续转发下去。通常此值小与broker节点的个数，如果集群中brokers有回环网络，则建议为1，比如:A->B,B->C,C->A。（避免networkConnector是链状，且有回环情况，良好的架构下，应该是星状结构，即每个broker都与其他brokers建立连接，而不是链状结构--pipleline）。在我们的项目里，设置值为2，主要是因为设置为1时经常发现出现集群无法转发的问题。相关问题在AMQ的JIRA上也有split usage of networkTTL for mesh topology
   怀疑这个配置我们配的有点问题。下周可以试验一下把messageTTL设置为-1（无限循环）试试

4. duplex：网络是否为双向的，默认为false。如果为true，则remote Broker不仅是“订阅者”，还可以作为消息的“生产者”，即remote Broker也会向Local Broker转发消息。我们通常是，每个broker均与其他broker建立单向的networkConnector，比如有三个broker A/B/C，那么在A上配置2个单向的：A->B，A->C，那么在B上配置：B->A，B->C，以此论推。

5. alwaysSyncSend： 向remote Broker转发消息时，是否总是同步发送。默认为false，即只对持久化消息采用同步发送；如果为true，那么对于非持久化消息也将采用同步发送。所谓同步发送，就是local Broker通过networkerConnector将消息发送给remote Broker后，阻塞并等到remote Broker返回ACK指令。这是消息存储担保的方式。我们使用默认值，这个配置对非持久化的topic订阅不生效。

6. staticBridge：是否为“静态”Bridge，默认false，即networkConnector可以通过Advisory通知来获取Consumer的变更，并调整转发策略。如果为true，那么broker将不关注任何Advisory(Consumer变更)，只会使用“staticallyIncludeDestination”配置创建必要的订阅。

未完待续