rabbitmq消息接收的可靠性机制

消费端的两种处理机制:

两种机制的区别, 第一种是在消费端出现异常, 系统执行的, 如果多次重试失败, 则可以抛出指定异常拒绝该消息(等同与reject)或者将消息发送到指定队列;

第二种ack机制必须要内部catch住消费者的异常, 手动的进行ack或者nack给rabbitmq , 然后rabbitmq根据配置重新发送消息或者直接舍弃该消息

1. spring.rabbitmq.listener.retry配置的重发是在消费端应用内处理的，不是rabbitqq重发. 因为retry是消费端内部处理的，包括异常也是内部处理，对于rabbitmq是不知道的

2.消息ack

a. 返回ack则表明消息被处理, rabbitmq删除消息,

b. nack或者reject并且requeue=true则rabbitmq重新发送该消息,requeue=false则讲消息丢弃或放入私信队列

nack和reject区别, 前者可以批量拒绝消息, reject只能单条消息拒绝

c. 如果rabbitmq发出的消息一直得不到服务端的相应, 则在

rabbitmq断开，连接后会自动重新推送（不管是网络问题还是宕机）

消费端应用重启，消息会自动重新推送

关于retry

spring.rabbitmq.listener.simple.retry.max-attempts=5 最大重试次数
spring.rabbitmq.listener.simple.retry.enabled=true 是否开启消费者重试（为false时关闭消费者重试，这时消费端代码异常会一直重复收到消息）
spring.rabbitmq.listener.simple.retry.initial-interval=5000 重试间隔时间（单位毫秒）
???? spring.rabbitmq.listener.simple.default-requeue-rejected=false 重试次数超过上面的设置之后是否丢弃（false不丢弃时需要写相应代码将该消息加入死信队列

如果消费一端的重试机制没有被启动, 而且Listener抛出异常的话, 那么该消息就会无限地被重试. 通常我们的做法是抛出AmqpRejectAndDontRequeueException以reject该消息, 同时如果有dead-letter queue被设置的话该消息就会被置入, 否则被丢弃

此外还可以配置MessageRecoverer对异常消息进行处理，此处理会在listener.retry次数尝试完并还是抛出异常的情况下才会调用，默认有两个实现：

@Bean
public MessageRecoverer messageRecoverer(RabbitTemplate rabbitTemplate){
return new RepublishMessageRecoverer(rabbitTemplate, "exchangemsxferror", "routingkeymsxferror");
}

public class RejectAndDontRequeueRecoverer implements MessageRecoverer {
protected Log logger = LogFactory.getLog(RejectAndDontRequeueRecoverer.class);
@Override
public void recover(Message message, Throwable cause) {
if (this.logger.isWarnEnabled()) {
this.logger.warn("Retries exhausted for message " + message, cause);
}
throw new ListenerExecutionFailedException("Retry Policy Exhausted", new AmqpRejectAndDontRequeueException(cause), message);
}
}

RepublishMessageRecoverer：将消息重新发送到指定队列，需手动配置
RejectAndDontRequeueRecoverer：如果不手动配置MessageRecoverer，会默认使用这个，实现仅仅是将异常打印抛出

两种方式在生产中的使用

第一种: 开启手动ack, 然后内部catch后直接处理，然后使用channel对消息进行确认(因为内部catch, 所以retry是一直无效的)

第二种: 不做内部catch, 直接使用retry尝试的次数达到后, 进行的操作来处理

测试1

首先配置

spring.rabbitmq.listener.simple.acknowledge-mode=manual

@RabbitListener(queues = "queue.item.search.test")
public void DocTest(org.springframework.amqp.core.Message message, Channel channel) {
System.out.println("****************************");
try {
System.out.println(message.getBody());
if (true)
throw new YuncaiException("");
channel.basicAck(message.getMessageProperties().getDeliveryTag(), false);
}catch (Exception e){
try {
channel.basicNack(message.getMessageProperties().getDeliveryTag(), false, false);
} catch (IOException e1) {
e1.printStackTrace();
}
}
}

//第二个参数，false只确认当前一个消息收到，true确认所有consumer获得的消息

channel.basicAck(message.getMessageProperties().getDeliveryTag(), false);

//第三个参数, false为直接抛弃, true为rabbitmq重新发送

channel.basicNack(message.getMessageProperties().getDeliveryTag(), false, true);

//第二个参数,第三个参数, false为直接抛弃, true为rabbitmq重新发送

channel.basicReject(message.getMessageProperties().getDeliveryTag(), true);

测试结果:

1. 当消费端收到消息,但没有ack, web控制台显示unack数为1, 当消费端重启后该消息再次被rabbitmq发送给消费端

2. 当nack时, 设置为false, 则该消息直接舍弃, 其实和ack后的结果是一样的

3. 当nack时, 设置为true, 该消息会一直被rabbitmq发送, 死循环

测试二

首先配置

spring.rabbitmq.listener.simple.retry.enabled=true
spring.rabbitmq.listener.simple.retry.max-attempts=3
spring.rabbitmq.listener.simple.acknowledge-mode=manual

@RabbitListener(queues = "queue.item.search.test")
public void DocTest(org.springframework.amqp.core.Message message, Channel channel) {
System.out.println("****************************");
System.out.println(message.getBody());
if (true)
throw new YuncaiException("");
try {
channel.basicAck(message.getMessageProperties().getDeliveryTag(), false);
} catch (IOException e) {
e.printStackTrace();
}
}

rabbitmq只做一次消息发送, 消费者内部自动重发了两次(1+2=3次), 之后消息停止发送, rabbitmq的web控制台unack数为1

关于springamqp做的autoAck(默认)

在当前线程结束没有抛出异常的情况下才会ack, 抛出异常则执行retry机制

总结:

如果使用springamqp默认的autoack,并且配置类retry次数, 则在抛出异常重试指定次数后消息被丢弃,相当于消费端发送了ack信号;

如果使用manualack,并且配置了retry次数, 在ack前抛出异常, 则在重试指定次数后, 该消息在broker中还是unack状态;

如果使用manualack,不管配置配置了retry与否, 包住所有可能的异常, 手动ack或者nack,决定broker是ack还是unack;

以上三种情况在接受消息的过程中, 消费者和broker连接中断((消费者宕掉),消息都会重新发送

来源：oschina

链接：https://my.oschina.net/xiaominmin/blog/4492209

标签

Spring AMQP

RabbitMQ

Spring