java

关注公众号 jb51net

关闭
首页 > 软件编程 > java > RabbitMq reply报错解决

RabbitMq报错reply-code=406 reply-text=PRECONDITION_FAILED解决

作者:刨红薯的小羊竿尔

这篇文章主要为大家介绍了RabbitMq报错reply-code=406 reply-text=PRECONDITION_FAILED分析解决,有需要的朋友可以借鉴参考下,希望能够有所帮助,祝大家多多进步,早日升职加薪

一、检查配置是否正确

今天看生产日志发现了很多的RabbitMq报错:reply-code=406, reply-text=PRECONDITION_FAILED - unknown delivery tag 1, class-id=60, method-id=80,全都是异常之后重复消费,重复报错。

unknown delivery tag 1-参考rabbitMQ的tag机制可知这条消息已经完成了消费;那么出现这个原因是配置不对了。

首先排查SimpleRabbitListenerContainerFactory是否加上手动ack

private SimpleRabbitListenerContainerFactory getSimpleRabbitListenerContainerFactory(ConnectionFactory connectionFactory) {
    SimpleRabbitListenerContainerFactory factory = new SimpleRabbitListenerContainerFactory();
    factory.setConnectionFactory(connectionFactory);
    //使用jackson进行消息序列与反序列
    factory.setMessageConverter(new Jackson2JsonMessageConverter());
    factory.setAcknowledgeMode(AcknowledgeMode.MANUAL); // 开启手动 ack
    return factory;
}

Jackson2JsonMessageConverter是rabbitmq 对java对象json序列化的支持,在发送消息时,会先将自定义的消息类序列化成json格式,再转成byte构造 Message,rabbitmq的ack就被设置为自动提交;需要手动开启ack,没得问题:factory.setAcknowledgeMode(AcknowledgeMode.MANUAL)。

其次检查配置文件,配置文件设置为手动ack

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

rabbitmq:
  host: 127.0.0.1
  port: 5672
  username: guest
  password: guest
  ###开启消息确认机制 confirms
  virtual-host: /
  publisher-confirms: true
  publisher-returns: true
  #rabbitmq配置加上手动应答
  listener:
      simple:
        acknowledge-mode: manual

二、rabbitmq消息重回队列,回到队尾

当出现异常时,我们需要把这个消息回滚到消息队列,有两种方式:

但是环境中的实际情况是,当消息回滚到消息队列时,这条消息不会回到队列尾部,而是仍是在队列头部,这时消费者会立马又接收到这条消息进行处理,接着抛出异常,进行回滚,如此反复进行。这种情况会导致消息队列处理出现阻塞,消息堆积,导致正常消息也无法消费

对于消息回滚到消息队列,我们希望方式是出现异常的消息到达消息队列尾部,这样既保证消息不会丢失,又保证了正常业务的进行

因此我们采取的解决方案是,将消息先进行应答,这时消息队列会删除该消息,同时再次发送该消息到消息队列,这时就实现了错误消息进行消息队列尾部的方案。

具体方案为:

//手动进行应答
channel.basicAck(message.getMessageProperties().getDeliveryTag(), false);
//重新发送消息到队尾
channel.basicPublish(message.getMessageProperties().getReceivedExchange(),
message.getMessageProperties().getReceivedRoutingKey(), MessageProperties.PERSISTENT_TEXT_PLAIN,
JSON.toJSONBytes(new Object()));

三、消息体本身有误

如果一个消息体本身有误,会导致该消息体,一直无法进行处理,而服务器中刷出大量无用日志

解决这个问题可以采取两种方案:

1、对于日常细致处理,分清哪些是可以恢复的异常,哪些是不可以恢复的异常。对于可以恢复的异常我们采取第三条中的解决方案,对于不可以处理的异常,我们采用记录日志,直接丢弃该消息方案。

2、对每条消息进行标记,记录每条消息的处理次数,当一条消息,多次处理仍不能成功时,处理次数到达我们设置的值时,我们就丢弃该消息,但需要记录详细的日志。

消息监听内的异常处理有两种方式:

1、内部catch后直接处理,然后使用channel对消息进行确认

2、配置RepublishMessageRecoverer将处理异常的消息发送到指定队列专门处理或记录。监听的方法内抛出异常貌似没有太大用处。因为抛出异常就算是重试也非常有可能会继续出现异常,当重试次数完了之后消息就只有重启应用才能接收到了,很有可能导致消息消费不及时。当然可以配置RepublishMessageRecoverer来解决,但是万一RepublishMessageRecoverer发送失败了呢。那就可能造成消息消费不及时了。所以即使需要将处理出现异常的消息统一放到另外队列去处理,个人建议两种方式:

以上就是RabbitMq报错reply-code=406 reply-text=PRECONDITION_FAILED解决的详细内容,更多关于RabbitMq reply报错解决的资料请关注脚本之家其它相关文章!

您可能感兴趣的文章:
阅读全文