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

  • 1
    点赞
  • 5
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值