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