ActiveMQ推拉模型与消息ACK

ActiveMQ的推拉模型
在上一篇博客中，讲到JMS有两种模型，一种是点对点，另一种是发布/订阅；对于消费者来说，我们可以将消费者获取消息的方式分为两种，即推拉模型。
推模型（Push方式）
由消息中间件主动的将消息推送给消费者；
拉模型（Pull方式）
由消费者主动向中间件拉取消息；
两种模式各有优势，Push方式可以尽快的将消息发送给消费者；而Pull方式的好处在于可以进一步的解除消费者对于消息中间件的依赖，通过后台任务去定期的访问消息队列中的消息。
Push方式的坏处是，如果一个消费者处理消息的能力很弱，而消息中间件不停的向其发送消息，则会导致消费者缓冲溢出；
Pull方法需要引进一个单独的服务进程，加大消耗的资源。
prefetch limit
ActiveMQ通过一个参数值prefetch limit来限制Push消息的数量。
当推送消息的数量到达了prefetch limit规定的数值时，消费者还没有向消息中间件返回ACK，消息中间件将不再继续向消费者推送消息。
用户可自定义对prefetch赋值，以下分为两种情况：
当prefetchACK为true时，prefetch的值必须大于0，表示需要限制推送的消息数量；
当prefetchACK为false时，prefetch可以大于等于0，当prefetch=0时，表明消费者使用pull方式获取消息，broker端将不会主动push消息给消费者；当prefetch>0时，表示开启了broker push模式，只要消费者返回了ACK标志，broker就会push消息给消费者。

optimizeACK（优化的ACK）：在Push模式中，broker将多条消息推送给消费者，消费者采用“延迟确认ACK”，消费者在消费消息后暂且不发送ACK，而是把它缓存下来(pendingACK)，等到这些消息的条数达到一定阀值时，只需要通过一个ACK指令把它们全部确认；这比对每条消息都逐个确认，在性能上要提高很多。

ACK模式与类型
ACK模式：

AUTO_ACKNOWLEDGE = 1 自动确认
CLIENT_ACKNOWLEDGE = 2 客户端手动确认
DUPS_OK_ACKNOWLEDGE = 3 自动批量确认
SESSION_TRANSACTED = 0 事务提交并确认

当我们在创建会话时，往往需要确定ACK的模式；

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

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上确认了消息)。

详细介绍可以参考：http://shift-alt-ctrl.iteye.com/blog/2020182

参考：
http://www.cnblogs.com/hapjin/p/5683648.html
http://www.cnblogs.com/charlesblc/p/6045238.html