activemq ack机制

1,同步,异步ack---消费端,服务端

2,ack立即确认,ack在优化的情况下阈值确认

3,ack模式,类型---重发,删除时机

发送端:

1,同步可以设置为异步,不需要等待 broker ack 生产端

2,队列满了之后就用游标

3,组合消息目的

发送端的重发需要硬编码

broker  协调端  ---响应ack:

协调端的重发送,根据ack类型自动不断重发---消费端选择手动ack的时候就需要接到消息,硬编码ack

接收端:

1,消息镜像队列---监控队列中所有经过的消息

2,消费端没有正常接受,  消费端 不同的 ack  broker会有不同的反应---例如:broker重发,broker取消删除队列消息,只有消费端才有多种ack模式

消费端的ack也分同步异步

ack模式是active-- session共享的,一旦制定所有的消费者都用此消费模式,每种ack模式下有不同的ack类型(服务会根据不同的响应在确定的模式下给出不同的类型)

一般是没有异常就是正确的确认类型,有异常抛出就是用类似需要重发的确认类型(try-catch可以控制即使出错也不重发)

CLIENT_ACKNOWLEDGE : 客户端手动确认 ,可以控制确认的时机,例如只有当正确消费后才确认

optimizeAcknowledge  ---是否开启优化

有ack就是消息到达网络是通的,至于具体是否成功处理就是需要具体的ack模式和类型处理

不开启即同步----就是立即确认(只是收到确认,不是处理成功确认,直到acknowledge才是消费成功)

开启优化之后才能设置ack模式,有了ack模式之后遇到具体的情况做具体的ack类型反馈,即使不立即确认也会在达到阈值后acknowledge,在acknoledge时

会把目前为止所有正确消费的消息确认

开始方式一:

    1) 在brokerUrl中增加如下查询字符串:   

String brokerUrl = "tcp://localhost:61616?" +   

                   "jms.optimizeAcknowledge=true" +   

                   "&jms.optimizeAcknowledgeTimeOut=30000" +   

                   "&jms.redeliveryPolicy.maximumRedeliveries=6";  

ActiveMQConnectionFactory factory = new ActiveMQConnectionFactory(brokerUrl);  

    2) 在destinationUri中,增加如下查询字符串:

Java代码  收藏代码

String queueName = "test-queue?customer.prefetchSize=100";  

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

Destination queue = session.createQueue(queueName);  

在事物型的消息中事物提交就是acknowledge

重发的消息1,存在硬盘上的,2管道中未acknowledge的消息

消费端有最大的容量,超出不再接收,假死,当然在达到prefech阈值之前会自动acknowledge(prefech就是为了批量push给消费端)

DUPS_OK_ACKNOWLEDGE :

AUTO_ACK + optimizeACK + (prefetch > 0)=自动确认+开启优化+获取阈值>0----批量acknowledge(阈值确认)

AUTO_ACK----直接acknowledge,来一条确认一条

超过了重发的次数就放入dead letter

参考:

https://blog.csdn.net/zhu_tianwei/article/details/46303535

http://shift-alt-ctrl.iteye.com/blog/2020182

猜你喜欢

转载自yuhuiblog6338999322098842.iteye.com/blog/2422903