RabbitMq消息确认和拒绝

今天夸平台和其他部门协作，需要给对方提供两个接口，但是最后发现两个项目用的是两套SSO，一个是正规SSO，一套是我们使用的”假SSO“，涉及的部门有4个。最后和对方系统的产品经理一起找了正规SSO领导寻求解决问题，沟通中发现此领导理尽然直呼我领导的领导的大名，真是尴尬，我都被他带了节奏，当着5个人的面说了我领导的领导的大名。打电话都不带称呼，直接说事。甚至直接给“假SSO”部门老大打电话，让对方把服务给停了，真是开眼界啊。最后该领导还给我们梳理了业务，并说我们犯的错还不大，并吐槽了现有的问题。最后查了一下此领导的信息，发现是公司元老！

言归正传，说一下RabbitMq中消费端的确认和拒绝。消息提供者将消息发送到RabbitMq，然后经过路由转发到具体的服务消费者。服务消费者则需要对消息进行确认，表示消息是否已经被送达。对应的有两种确认方式，一种是自动确认，一种是手动，相关的属性为autoAck，手动确认需要服务消费者显式调用basic.ack命令进行确认。

当autoAck为true表示rabbitmq发送消息到消费者操作系统的套接字缓冲区即可让rabbitmq将消息队列中该消息删除。但是如果套接字缓存区崩溃，就会存在消费者应用程序没有读到消息，消息就被从消息队列中移除。而autoAck为fale则表示消息必须要被消费者应用程序手动的调用basic.ack进行确认。所以安全性更好！

在RabbitMq管理界面中我们可以看到消息队列中消息的统计情况。

如果我们的服务消费者需要对获取到的消息进行拒绝。那么就调用basic.reject命令。

channel.basicReject(deliveryTag,requeue);

这里的deliveryTag是一个64位长整数，第二个参数requeue表示是否重新加入到队列中。为false表示立即从队列中移除。

basic.reject只能拒绝一条消息。拒绝批量消息则需要basic.Nack这个命令。

channel.basicNack(deliveryTag,true,true);

其中第二个参数multiple设置为false表示拒绝编号为delivertag这个消息，如果设置为true表示拒绝deliveryTag前边的所有未被当前消费者确认的消息。

requeue设置为false，可以启动死信队列。死信队列可以通过检测被拒绝或者未被送达的消息，用于追踪问题。

具体方法为：

//默认为true，表示重新发送未被确认的消息，发送到本机上。
RecoverOk basicRecover() throws IOException;
//如果为false，表示同一条消息会被发送到与之前相同的消费者上。
RecoverOk basicRecover(boolean var1) throws IOException;