activemq控制发送频率_activeMQ 使用总结（机制介绍）

1 基本处理方式

1.1 topic(publish-subscribe)

发布订阅模式，发布者发布消息到broker，所有订阅者都会接收到相同消息的copy。

1.2 queue(p2p)

p2p是生产者生成消息，经过broker-queue，只能有一个消费者处理。在p2p的场景里，相互通信的双方是通过一个类似于队列的方式来进行交流。和前面pub-sub的区别在于一个topic有一个发送者和多个接收者，而在p2p里一个queue只有一个发送者和一个接收者。

下图为queue处理过程，以及各种ack_type回复的处理流程，这些ack_type配合ack_mode进行，由jms内部控制。

1. 获得JMS connection factory. 通过我们提供特定环境的连接信息来构造factory。

2. 利用factory构造JMS connection

3. 启动connection

4. 通过connection创建JMS session.

5. 指定JMS destination.

6. 创建JMS producer或者创建JMS message并提供destination.

7. 创建JMS consumer或注册JMS message listener.

8. 发送和接收JMS message.

9. 关闭所有JMS资源，包括connection, session, producer, consumer等。

1.3 request-response(p2p)

和前面两种方式比较起来，request-response的通信方式很常见，但是不是默认提供的一种模式。在前面的两种模式中都是一方负责发送消息而另外一方负责处理。而我们实际中的很多应用相当于一种一应一答的过程，需要双方都能给对方发送消息。于是请求-应答的这种通信方式也很重要。它也应用的很普遍。

请求-应答方式并不是JMS规范系统默认提供的一种通信方式，而是通过在现有通信方式的基础上稍微运用一点技巧实现的。下图是典型的请求-应答方式的交互过程：

在JMS里面，如果要实现请求/应答的方式，可以利用JMSReplyTo和JMSCorrelationID消息头来将通信的双方关联起来。另外，QueueRequestor和TopicRequestor能够支持简单的请求/应答过程。

2 生产模式

通过创建producer,然后调用send接口实现。

3 消费模式

在spring框架中使用JMS传递消息有两种方式：JMS template和message listener Container，前者用于同步收发消息，后者用于异步收发消息。

3.1 同步方式

同步方式是创建consumer，通过session进行receive()方式接收消息。

3.2 异步方式

异步方式是通过实现messageListener的onMessage()接口实现，在该接口中完成消息处理。

4 可靠性机制

4.1 AUTO_ACKNOWLEDGE

Session.AUTO_ACKNOWLEDGE(自动确认模式)

当消息成功的从receive方法返回时，或者从MessageListener接口的onMessage方法成功返回时，会话自动确认客户端的消息接收。

自动确认,这就意味着消息的确认时机将有consumer择机确认."择机确认"似乎充满了不确定性,这也意味着,开发者必须明确知道"择机确认"的具体时机,否则将有可能导致消息的丢失,或者消息的重复接受.那么在ActiveMQ中,AUTO_ACKNOWLEDGE是如何运作的呢?

1) 对于consumer而言，optimizeAcknowledge属性只会在AUTO_ACK模式下有效。

2) 其中DUPS_ACKNOWLEGE也是一种潜在的AUTO_ACK,只是确认消息的条数和时间上有所不同。

3) 在“同步”(receive)方法返回message之前,会检测optimizeACK选项是否开启，如果没有开启，此单条消息将立即确认，所以在这种情况下，message返回之后，如果开发者在处理message过程中出现异常，会导致此消息也不会redelivery,即"潜在的消息丢失"；如果开启了optimizeACK，则会在unAck数量达到prefetch * 0.65时确认，当然我们可以指定prefetchSize = 1来实现逐条消息确认。

4) 在"异步"(messageListener)方式中,将会首先调用listener.onMessage(message),此后再ACK,如果onMessage方法异常,将导致client端补充发送一个ACK_TYPE为REDELIVERED_ACK_TYPE确认指令；如果onMessage方法正常,消息将会正常确认(STANDARD_ACK_TYPE)。此外需要注意，消息的重发次数是有限制的，每条消息中都会包含“redeliveryCounter”计数器，用来表示此消息已经被重发的次数，如果重发次数达到阀值，将会导致发送一个ACK_TYPE为POSION_ACK_TYPE确认指令,这就导致broker端认为此消息无法消费,此消息将会被删除或者迁移到"dead letter"通道中。

因此当我们使用messageListener方式消费消息时，通常建议在onMessage方法中使用try-catch,这样可以在处理消息出错时记录一些信息，而不是让consumer不断去重发消息；如果你没有使用try-catch,就有可能会因为异常而导致消息重复接收的问题,需要注意你的onMessage方法中逻辑是否能够兼容对重复消息的判断。

4.2 CLIENT_ACKNOWLEDGE

Session.CLIENT_ACKNOWLEDGE(客户端确认模式)

客户端通过调用消息的acknowledge方法签收消息。在这种模式中，签收是在会话层上进行：签收一个已消费的消息会自动地签收这个Session所有已消费消息的收条。

客户端手动确认，这就意味着AcitveMQ将不会“自作主张”的为你ACK任何消息，开发者需要自己择机确认。在此模式下，开发者需要需要关注几个方法：

1) message.acknowledge()，

2) ActiveMQMessageConsumer.acknowledege()，

3) ActiveMQ