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