ActiveMQ配置⽂件详解ActiveMQ 配置⽂件详解
下⾯是补充
1.broker元素(代理的属性)
--当前代理为备机代理
shutdownOnMasterFailure，默认值为false，如果配置为true，则主机失效后，备机代理(当前代理)会⾃动关闭
--当前代理为主机代理
waitForSlave 默认值为false ，如果配置为true，则主机代理在备机连接好之前，不接收任何客户端和⽹络连接shutdownOnSlaveFailure 默认值为false ，如果配额为true，则与备机失去连接后，主机代理会⾃动关闭.
这样就保证了备机与主机永远是同步的.
2 destinationPolicy 元素(消息⽬的地策略配置)
该元素是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(订阅恢复策略)    policyEntry元素 属性 及其⼦元素
(1) 分发策略 dispatchPolicy
因为,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.
针对慢速消费者采取的策略.
慢速消费者在订阅⾮持久化主题时可能会导致问题.因为慢速消费者会强制代理将消息缓存在其
内存中,⼀旦内存填满了，代理会强制消息⽣产者降低⽣产消息的速度.这样就降低了快速消费者
的处理速度.因为消息⽣产者不再快速产⽣消息了.
Currently we have a strategy that  lets you configure the maximum number  of
activemq默认端口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>
针对⾮持久化(Non-Durable)主题⽽⾔. 持久化(durable)主题和队列不在内存中缓存.
客户端需要在创建消费者之前，创建主题时采⽤特殊⽅式:
ConnectionFactory fac = new ActiveMQConnectionFactory();
Connection connection = ateConnection();
connection.start();
Session session = ateSession(false,Session.AUTO_ACKNOWLEDGE);
Topic topic = ateTopic("TEST.active=true");
MessageConsumer consumer = ateConsumer(topic);
注意上⾯的ateTopic("TEST.active=true");
中设置active=true将创建的消费者设置为可追溯消费者.
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.
代理端就通过 <subscriptionRecoveryPolicy>配置策略

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。