消费端在处理消息过程中可能会报错，此时该如何重新处理消息呢？
一般来说RabbitMQ有个方法channel.basicNack()能够让消息回到队列中，这样可以实现重试。但是这样没有明确重试次数，可能会造就无限重试，这是一个致命的缺点。
下面提供几种解决方案
- 用redis或者mongo等第三方存储当前重试次数。
- 在header中添加重试次数，并且使用channel.basicPublish() 方法重新将消息发送出去后将重试次数加1。
- 使用spring-rabbit中自带的retry功能。
这一篇介绍使用spring-rabbit自带的retry功能
配置
需要简单的配置即可开启
spring:
rabbitmq:
listener:
simple:
acknowledge-mode: auto # 消息确认方式，其有三种配置方式，分别是none、manual(手动ack) 和auto(自动ack) 默认auto
retry:
enabled: true #监听重试是否可用
max-attempts: 5 #最大重试次数 默认为3
initial-interval: 2000 # 传递消息的时间间隔 默认1s
mq:
queueBinding:
queue: prod_queue_pay
exchange:
name: exchang_prod_pay
type: topic
key: prod_pay
此时我们的消费者代码如下:
@RabbitListener(bindings = @QueueBinding(
value = @Queue(value = "${mq.queueBinding.queue}",autoDelete = "false"),
exchange = @Exchange(value = "${mq.queueBinding.exchange.name}",type = "${mq.queueBinding.exchange.type}"),
key = "${mq.queueBinding.key}"
))
public void infoConsumption(String data, Channel channel, @Header(AmqpHeaders.DELIVERY_TAG) long tag) throws Exception {
log.info("RabbitReceiver.infoConsumption() data = {}",data);
int i = 10 /0;
log.error("支付异常，重新将消息放入mq");
System.out.println(count++);
}
每次重试时间间隔为2秒，与配置相符
注意：
重试并不是RabbitMQ重新发送了消息，仅仅是消费者内部进行了重试，换句话说就是重试跟mq没有任何关系；
因此上述消费者代码不能添加try{}catch(){}，一旦捕获了异常，在自动ack模式下，就相当于消息正确处理了，消息直接被确认掉了，不会触发重试的；
MessageReCoverer
上面的例子在测试中我们还发现了一个问题，就是经过5次重试以后，控制台输出了一个异常的堆栈日志，然后队列中的数据也被ack掉了（自动ack模式,也就是确认消费了），首先我们看一下这个异常日志是什么。
org.springframework.amqp.rabbit.support.ListenerExecutionFailedException:
Retry Policy Exhausted
出现消息被消费掉并且出现上述异常的原因是因为在构建SimpleRabbitListenerContainerFactoryConfigurer类时使用了MessageRecoverer接口，这个接口有一个recover方法，用来实现重试完成之后对消息的处理，源码如下：
public final class SimpleRabbitListenerContainerFactoryConfigurer
extends AbstractRabbitListenerContainerFactoryConfigurer<SimpleRabbitListenerContainerFactory> {
@Override
public void configure(SimpleRabbitListenerContainerFactory factory, ConnectionFactory connectionFactory) {
PropertyMapper map = PropertyMapper.get();
RabbitProperties.SimpleContainer config = getRabbitProperties().getListener().getSimple();
configure(factory, connectionFactory, config); >> 1
map.from(config::getConcurrency).whenNonNull().to(factory::setConcurrentConsumers);
map.from(config::getMaxConcurrency).whenNonNull().to(factory::setMaxConcurrentConsumers);
map.from(config::getBatchSize).whenNonNull().to(factory::setBatchSize);
}
}
注意标记为>> 1的configure方法
ListenerRetry retryConfig = configuration.getRetry();
if (retryConfig.isEnabled()) {
RetryInterceptorBuilder<?, ?> builder = (retryConfig.isStateless()) ? RetryInterceptorBuilder.stateless()
: RetryInterceptorBuilder.stateful();
RetryTemplate retryTemplate = new RetryTemplateFactory(this.retryTemplateCustomizers)
.createRetryTemplate(retryConfig, RabbitRetryTemplateCustomizer.Target.LISTENER);
builder.retryOperations(retryTemplate);
MessageRecoverer recoverer = (this.messageRecoverer != null) ? this.messageRecoverer
: new RejectAndDontRequeueRecoverer(); //<1>
builder.recoverer(recoverer);
factory.setAdviceChain(builder.build());
注意看<1>处的代码，默认使用的是RejectAndDontRequeueRecoverer实现类，根据实现类的名字我们就可以看出来该实现类的作用就是拒绝并且不会将消息重新发回队列，我们可以看一下这个实现类的具体内容：
public class RejectAndDontRequeueRecoverer implements MessageRecoverer {
protected Log logger = LogFactory.getLog(RejectAndDontRequeueRecoverer.class); // NOSONAR protected
@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);
}
}
上述源码给出了异常的来源，但是未看到拒绝消息的代码，猜测应该是使用aop的方式实现的，此处不再继续深究。
MessageRecoverer接口还有另外两个实现类，分别是RepublishMessageRecoverer和ImmediateRequeueMessageRecoverer，顾名思义就是重新发布消息和立即重新返回队列，下面我们分别测试一个这两个实现类：
RepublishMessageRecoverer(重新发布)
先创建一个异常队列，然后与交换机绑定进行绑定,绑定之后设置MessageRecoverer
@Autowired
private RabbitTemplate rabbitTemplate;
private static String errorTopicExchange = "error-topic-exchange";
private static String errorQueue = "error-queue";
private static String errorRoutingKey = "error-routing-key";
//创建异常交换机
@Bean
public TopicExchange errorTopicExchange(){
return new TopicExchange(errorTopicExchange,true,false);
}
//创建异常队列
@Bean
public Queue errorQueue(){
return new Queue(errorQueue,true);
}
//队列与交换机进行绑定
@Bean
public Binding BindingErrorQueueAndExchange(Queue errorQueue,TopicExchange errorTopicExchange){
return BindingBuilder.bind(errorQueue).to(errorTopicExchange).with(errorRoutingKey);
}
//设置MessageRecoverer
@Bean
public MessageRecoverer messageRecoverer(){
//AmqpTemplate和RabbitTemplate都可以
return new RepublishMessageRecoverer(rabbitTemplate,errorTopicExchange,errorRoutingKey);
}
此时启动服务，查看处理结果：
通过控制台可以看到，消息重试5次以后直接以新的routingKey发送到了配置的交换机中，此时再查看监控页面，可以看原始队列中已经没有消息了，但是配置的异常队列中存在一条消息
ImmediateRequeueMessageRecoverer(即时队列)
测试ImmediateRequeueMessageRecoverer，修改messageRecoverer方法
@Bean
public MessageRecoverer messageRecoverer(){
return new ImmediateRequeueMessageRecoverer();
}
重试5次之后，返回队列，然后再重试5次，周而复始直到不抛出异常为止，这样会影响后续的消息消费。
总结：
通过上面的测试，对于重试之后仍然异常的消息，可以采用RepublishMessageRecoverer，将消息发送到其他的队列中，再专门针对新的队列进行处理。
死信队列
除了可以采用上述RepublishMessageRecoverer，还可以采用死信队列的方式处理重试失败的消息。
首先创建死信交换机、死信队列以及两者的绑定
private static String dlTopicExchange = "dl-topic-exchange";
private static String dlQueue = "dl-queue";
private static String dlRoutingKey = "dl-routing-key";
//创建交换机
@Bean
public TopicExchange dlTopicExchange(){
return new TopicExchange(dlTopicExchange,true,false);
}
//创建队列
@Bean
public Queue dlQueue(){
return new Queue(dlQueue,true);
}
//队列与交换机进行绑定
@Bean
public Binding BindingErrorQueueAndExchange(Queue dlQueue, TopicExchange dlTopicExchange){
return BindingBuilder.bind(dlQueue).to(dlTopicExchange).with(dlRoutingKey);
}
死信交换机的定义和普通交换机的定义完全相同，队列绑定死信交换机与绑定普通交换机的方式完全相同，死信交换机就是一个普通的交换机，只是换了一个叫法而已，没有什么特殊之处
创建业务队列、业务交换机，以及两者的绑定
@Value("${mq.queueBinding.queue}")
private String queueName;
@Value("${mq.queueBinding.exchange.name}")
private String exchangeMame;
@Value("${mq.queueBinding.key}")
private String key;
/**
绑定死信交换机需要给队列设置如下两个参数
* 业务队列
* @return
*/
@Bean
public Queue payQueue(){
Map<String,Object> params = new HashMap<>();
//声明当前队列绑定的死信交换机
params.put("x-dead-letter-exchange",dlTopicExchange);
//声明当前队列的死信路由键
params.put("x-dead-letter-routing-key",dlRoutingKey);
return QueueBuilder.durable(queueName).withArguments(params).build();
}
@Bean
public TopicExchange payTopicExchange(){
return new TopicExchange(exchangeMame,true,false);
}
//队列与交换机进行绑定
@Bean
public Binding BindingPayQueueAndPayTopicExchange(Queue payQueue, TopicExchange payTopicExchange){
return BindingBuilder.bind(payQueue).to(payTopicExchange).with(key);
}
rabbitmq图形化页面添加
此时消费者的代码如下
@RabbitListener(queues = "${mq.queueBinding.queue}")
public void infoConsumption(String data, Channel channel, @Header(AmqpHeaders.DELIVERY_TAG) long tag) throws Exception {
//log.info("RabbitReceiver.infoConsumption() data = {}",data);
log.info("重试次数 = {}",count++);
int i = 10 /0;
}
启动服务，可以看到同时创建了业务队列以及死信队列
在业务队列上出现了DLX以及DLK的标识，标志已经绑定了死信交换机以及死信路由键，此时调用生产者发送消息，消费者在重试5次后，由于MessageCover默认的实现类是RejectAndDontRequeueRecoverer，又因为业务队列绑定了死信队列，因此消息会从业务队列中删除，同时发送到死信队列中。
retry使用场景
上面说了什么是重试，以及如何解决重试造成的数据丢失，那么怎么来选择重试的使用场景呢？
是否是消费者只要发生异常就要去重试呢？其实不然，假设下面的两个场景：
http下载视频或者图片或者调用第三方接口
空指针异常或者类型转换异常（其他的受检查的运行时异常）
很显然，第一种情况有重试的意义，第二种没有。
对于第一种情况，由于网络波动等原因造成请求失败，重试是有意义的；
对于第二种情况，需要修改代码才能解决的问题，重试也没有意义，需要的是记录日志以及人工处理或者轮询任务的方式去处理。
注：retry只能在自动ack模式下使用。如果一定要在手动ack模式下使用retry功能，需保证消息能在有限次重试过程中可以重试成功，否则超过重试次数，又没办法执行ack或者nack，消息就会一直处于unack,并不会转发到死信队列
//抛出NullPointerException异常则重新入队列
throw new NullPointerException("消息消费失败");
//当抛出的异常是AmqpRejectAndDontRequeueException异常的时候，则消息会被拒绝，且requeue=false
throw new AmqpRejectAndDontRequeueException("消息消费失败");
//当抛出ImmediateAcknowledgeAmqpException异常，则消费者会被确认
throw new ImmediateAcknowledgeAmqpException("消息消费失败");
