关于ActiveMQ消息传送机制以及消息确认机制

下面分享的是一篇关于ActiveMQ与其消费者间的消息传送机制以及消息确认机制的文章，先附上链接：shift-alt-ctrl.iteye.com/blog/2020182

该文章中详细描述了一条消息从生产者到中间件再到消费者的传送处理过程，而我们的系统中常会在消息者从中间件获得并处理消息这一环节出现问题，因此可以参考其中处理细节，了解问题所在。

---

消息的推/拉

对于消息在中间件及消费者间的传送，我们可以根据消费者的主动或被动获取消息来区分消息的推/拉模式。当中间件主动传送消息给消费者，我们可以认为这是一种推的模式；当消费者在消费完之前的消息后主动到中间件获取下一条消息，则我们可以认为这是一种拉的模式。

消息的推/拉都与中间件的一个参数有关，prefetchSize。其详细作用可参考官网说明：activemq.apache.org/what-is-the-prefetch-limit-for.html

当prefetch > 0 时，消息将会由中间件主动推给消费者；当prefetch = 0 时，消息将由消费者消费完上一消息后主动去获取，此时消费者会发送一个pullCommand如下：

由于默认值设置如下：

persistent queues (default value:1000)

non-persistent queues (default value:1000)

persistent topics (default value:100)

non-persistent topics (default value:Short.MAX_VALUE - 1)

当未设置prefetch值时一般都是采用推的模式进行消息传递。

---

消息的ACK机制

一条消息从producer端发出之后，一旦被broker正确保存，那么它将会被consumer消费，然后ACK，broker端才会删除；

由分享文章中我们可以看到消息消费及确认如下图所示：

从消息的消费过程来看，ACK分为多种类型，其用于确认消费者消费消息的不同阶段及状态，这一机制确保队列消息的不重复消费这一特点。

DELIVERED_ACK_TYPE= 0    消息"已接收"，但尚未处理结束

STANDARD_ACK_TYPE= 2    "标准"类型,通常表示为消息"处理成功"，broker端可以删除消息了

POSION_ACK_TYPE= 1    消息"错误",通常表示"抛弃"此消息，比如消息重发多次后，都无法正确处理时，消息将会被删除或者DLQ(死信队列)

REDELIVERED_ACK_TYPE= 3    消息需"重发"，比如consumer处理消息时抛出了异常，broker稍后会重新发送此消息

INDIVIDUAL_ACK_TYPE= 4    表示只确认"单条消息",无论在任何ACK_MODE下

UNMATCHED_ACK_TYPE= 5    在Topic中，如果一条消息在转发给“订阅者”时，发现此消息不符合Selector过滤条件，那么此消息将 不会转发给订阅者，消息将会被存储引擎删除(相当于在Broker上确认了消息)。

最后再附上一篇文章，该博客整理了消息队列-推/拉模式学习 & ActiveMQ及JMS学习：

www.cnblogs.com/charlesblc/p/6045238.html

---

不尽之处请指正，以求进步！