ActiveMQ 配置文件详解

ActiveMQ 配置文件详解

参考,http://jackyin5918.iteye.com/admin/blogs/2004138

下面是补充

1.broker元素(代理的属性)

--当前代理为备机代理

shutdownOnMasterFailure,默认值为false,如果配置为true,则主机失效后,备机代理(当前代理)会自动关闭

--当前代理为主机代理

waitForSlave 默认值为false ,如果配置为true,则主机代理在备机连接好之前,不接收任何客户端和网络连接

shutdownOnSlaveFailure 默认值为false ,如果配额为true,则与备机失去连接后,主机代理会自动关闭.

这样就保证了备机与主机永远是同步的.

2 destinationPolicy 元素(消息目的地策略配置)

官方文档:http://activemq.apache.org/per-destination-policies.html

分发策略:http://activemq.apache.org/dispatch-policies.html

该元素是broker子元素 配置示例如下:

<destinationPolicy>

      <policyMap>

        <policyEntries>

          <policyEntry topic="FOO.>">

            <dispatchPolicy>

              <roundRobinDispatchPolicy />

            </dispatchPolicy>

            <subscriptionRecoveryPolicy>

              <lastImageSubscriptionRecoveryPolicy />

            </subscriptionRecoveryPolicy>

          </policyEntry>

          <policyEntry topic="ORDERS.>">

            <dispatchPolicy>

              <strictOrderDispatchPolicy />

            </dispatchPolicy>

            <!--  1 minutes worth -->

            <subscriptionRecoveryPolicy>

              <timedSubscriptionRecoveryPolicy recoverDuration="60000" />

            </subscriptionRecoveryPolicy>

          </policyEntry>

          <policyEntry topic="PRICES.>">

            <!-- lets force old messages to be discarded for slow consumers -->

            <pendingMessageLimitStrategy>

              <constantPendingMessageLimitStrategy limit="10"/>

            </pendingMessageLimitStrategy>

            <!--  10 seconds worth -->

            <subscriptionRecoveryPolicy>

              <timedSubscriptionRecoveryPolicy recoverDuration="10000" />

            </subscriptionRecoveryPolicy>

             

          </policyEntry>

          <policyEntry tempTopic="true" advisoryForConsumed="true" />

          <policyEntry tempQueue="true" advisoryForConsumed="true" />

        </policyEntries>

      </policyMap>

    </destinationPolicy>

    

    上面示例配置 仅仅配置了 dispatchPolicy(分发策略) 和 subscriptionRecoveryPolicy(订阅恢复策略)

    

    更多策略,参考http://activemq.apache.org/schema/core/activemq-core-5.8.0-schema.html#policyEntry

    policyEntry元素 属性 及其子元素

    

    (1) 分发策略 dispatchPolicy 

    参考 :http://activemq.apache.org/dispatch-policies.html

    http://activemq.apache.org/what-is-the-prefetch-limit-for.html

    

    参考 http://jackyin5918.iteye.com/blog/2004238 了解 prefetch limit参数

    因为,ActiveMQ 设计成高性能和高吞吐量,所以默认时ActiveMQ尝试已最快的速度达到

    消息消费者的prefetch limit值.

    而默认的prefetch limit配置可能不适合有些应用场景.

    比如,假设只发送了很少数量的消息,但是默认时prefetch limit值很大,此时消息可能只发

    送给一个消费者了.另外,假如只发送很少数量的消息,并且每一个消息的处理时间很长,同时

    有很多消费者,因为prefetch limit设置过大,则消息值发给同一个消费者,所有消息由这一个

    消费者处理,其他消费者闲置造成资源浪费,消息处理时间增长.

    

    主要介绍两种 <roundRobinDispatchPolicy /> 随机发送策略 和 <strictOrderDispatchPolicy /> 严格发送策略

    

    对于队列来说,可以设置分发策略为 随机分发,还是严格分发.

    随机分发是尽可能随机发送消息给消费者,而严格分发是发送消息给上一个消费者,直到消息数量

    达到该消费者设置的prefetch limit,然后再选择下一个消费者发送消息.

    

    对于主题来说,默认的策略是 SimpleDispatchPolicy ,该策略将消息发送给所有订阅者.

    SimpleDispatchPolicy 优先网络分发策略将消费发送给来自高优先级网络中的消费者

    this is useful in a loop network topology where there is more than route to a consumer.

    

    (2)<pendingMessageLimitStrategy> 

    

    Sets  the strategy  to calculate  the maximum  number of  messages that  are

    allowed to be  pending on consumers  (in addition to  their prefetch sizes).

    Once the limit is reached, non-durable topics can then start discarding  old

    messages. This  allows us  to keep  dispatching messages  to slow  consumers

    while not blocking fast consumers and discarding the messages oldest first.

    

    http://activemq.apache.org/slow-consumer-handling.html

    

    针对慢速消费者采取的策略.

    慢速消费者在订阅非持久化主题时可能会导致问题.因为慢速消费者会强制代理将消息缓存在其

    内存中,一旦内存填满了,代理会强制消息生产者降低生产消息的速度.这样就降低了快速消费者

    的处理速度.因为消息生产者不再快速产生消息了.

    

    Currently we have a strategy that  lets you configure the maximum number  of

    matched messages the broker will keep  around for a consumer in addition  to

    its prefetch buffer. Once this maximum is reached, as new messages come  in,

    older messages are discarded.  This allows you to  keep the RAM for  current

    messages and keep  sending messages to  a slow consumer  but to discard  old

    messages.

    

    当前使用一种策略,让你可以配置 在消费者中缓存的未确认的消息数量超过prefetch limit后,

    代理可以为每一个消费者缓存的消息数量.一旦缓存的消息数量超过这个设置的值,则缓存的旧

    消息将会被抛弃(就是代理每一个消息消费者缓存的数量有限制了,这样代理用于每个消费者缓存消息

    的空间就小了,这样为所有消费者缓存消息的空间之和就小了).这样可以节约代理的RAM,进而可以缓

    存更多消息,也就不会轻易的将代理缓存充满,代理就不会强迫消息消费者减慢生产消息的速度.

    这样,随着生产者继续快速生产消息,快速消费者仍然可以快速消费消息.

    

    有两种策略:

    <constantPendingMessageLimitStrategy limit="50"/> 表示在消费者的消息

    达到prefetch limit值后,代理会为每个消费者缓存固定数量的消息,这里配置为50个.

    

    <prefetchRatePendingMessageLimitStrategy multiplier="2.5"/> 配置为prefetch limit值 倍数

    上面配置表示代理会为每个消费者缓存消息个数为 prefetch limit值 * 2.5

    

    (3)<subscriptionRecoveryPolicy>

    

      文档:http://activemq.apache.org/subscription-recovery-policy.html

     针对非持久化(Non-Durable)主题而言. 持久化(durable)主题和队列不在内存中缓存.

     

     客户端需要在创建消费者之前,创建主题时采用特殊方式:

     ConnectionFactory fac = new ActiveMQConnectionFactory();

 Connection connection = fac.createConnection();

 connection.start();

 Session session = connection.createSession(false,Session.AUTO_ACKNOWLEDGE);

 Topic topic = session.createTopic("TEST.TOPIC?consumer.retroactive=true");

 MessageConsumer consumer = session.createConsumer(topic);

 注意上面的session.createTopic("TEST.TOPIC?consumer.retroactive=true");

 中设置consumer.retroactive=true将创建的消费者设置为可追溯消费者.

 文档:http://activemq.apache.org/retroactive-consumer.html  

 A    retroactive  consumer is  just  a  regular  JMS  Topic consumer   who

 indicates that at   the start of  a subscription  every  attempt should be

 used to go back  in time and send any old  messages (or the last   message

 sent on that  topic) that the consumer may have missed.

 可追溯消费者,是一个标准的主题消费者(注意是主题),可追溯表示在消费者开始订阅时,

 代理要尽可能的及时尝试发送所有该消费者错过的任何该主题的旧消息

 (或者发送给主题的最后一个消息).

 限制

 Retroactive consumer will not consistently work when used across a network of brokers.

In the case of topics, when we connect broker A to broker B, broker B will

send broker A all the subscriptions  that it has received. Since Broker  A

replicates messages to each subscription,  and we want to avoid  receiving

duplicates at broker B,  we can't send broker  A more than 1  subscription

for the same topic. So our network bridges keep track of the subscriptions

sent across and  only send the  first subscription to  a topic. Subsequent

subscriptions increment the reference  count of the subscription,  but the

subscription is not actually sent.

This in essence is  the problem. If the  first subscription to a  topic is

not retroactive, it  is sent B  to A, and  the B broker  will not get  the

retroactive   messages.   Then    subsequent   subscriptions   could    be

(retroactive), but  it will  not cause  retroactive message  to sent  from

broker A to broker B since the subsequent subscription will not be sent to

broker A.

涉及到重分发策略(Redelivery Policy,http://activemq.apache.org/redelivery-policy.html)

代理端就通过 <subscriptionRecoveryPolicy>配置策略

文档:http://activemq.apache.org/subscription-recovery-policy.html

常用策略如下:

THE ACTIVEMQ FIXED SIZE SUBSCRIPTION RECOVERY POLICY

  ACTIVEMQ固定尺寸订阅恢复策略

  THE ACTIVEMQ FIXED COUNT SUBSCRIPTION RECOVERY POLICY

  固定数量策略

  THE ACTIVEMQ QUERY-BASED SUBSCRIPTION RECOVERY POLICY

  基于查询的策略

  THE ACTIVEMQ TIMED SUBSCRIPTION RECOVERY POLICY

  时间策略

  THE ACTIVEMQ LAST IMAGE SUBSCRIPTION RECOVERY POLICY

  最终映像策略

  THE ACTIVEMQ NO SUBSCRIPTION RECOVERY POLICY

  无缓存策略

3 主备机配置

拷贝一份主机的配置文件,作为备机配置文件,

然后在备机的配置文件中的broker元素下面添加配置

<services>

<masterConnector 

remoteURI="tcp://remotehost:62001"

userName="Rob" 

password="Davies"

/>

</services>

这种配置 在5.8版本中已经被移除了,不支持这种配置.