RabbitMQ延迟队列消息路由失败（312 NO_ROUTE）原因及处理

消息路由失败 消息路由失败的处理方式有以下两种： mandatory和immediate是channel.basicPublish方法中的两个参数，它们都有当消息传递过程中不可达目的地时将消息返回给生产者的功能。 RabbitMQ提供的备份交换器(Altemate Exchange )可以将未能被交换器路由的消息(没有绑定队列或者没有匹配的绑定〉存储起来，而不用返回给客户端。 man...

Rabbitmq 发送方确认

RabbitMQ 消息可靠性（消息至少被成功消费一次） 实现延迟消息投递 （延迟对列） 高可用（集群） 解决消息堆积问题（持久化） 消息可靠性 生产者消息丢失：–>生产者确认机制 - 消息未到达交换机 （成功ACK 不成功NACK） - 消息到达交换机，未到达队列 （不成功ACK+报错） MQ服务挂了，队列中的消息丢失 -->队列持久化（ durable ） consumer接收消息但是未成功消费 -->消费者确认机制+消费者失败重试机制 (成功ACK 失败NACK) 生产

【代码】RabbitMQ延迟队列消息路由失败（312 NO_ROUTE）原因及解决方法。

大家在使用某宝的时候应该会遇到这样的场景, 自己选择的商品之后, 点击了提交订单, 但是并没有发起支付, 随后在待支付的页面就会看见刚刚的订单正在倒计时, 并且提示剩余时间 这里就会用到延迟队列, 等待时间倒计时结束后, 用户仍没有支付订单, 就会发送消息取消订单。当消息发送到延迟交换机中, 正常情况下交换机应该立即发送消息给队列, 不具备消息的存储功能, 而延迟交换机会帮你把消息暂存, 等过完5秒钟后才发送, 所以消息没有进行转发才导致刚刚的报错.这里值得注意的是, 在声明参数的时候多了一个。...

为什么会出现这种情况呢，因为第一次消息推送，是由延迟插件进行处理的，此时消息需要等待延迟并未进入队列进行消费，所以消息返回code是312：NO_ROUTE，无法路由到队列，因为设置了mandatory为true，即监听消息无法抵达队列时，进入setReturnsCallback方法进行失败消息处理，在上面的配置中，进入setReturnsCallback会再次进行推送。目前采用的是第3种方案。

前提是对rabbitmq有一定的了解，比如虚拟主机，交换机，队列，信道，绑定，路由键，direct，fanout，topic等。我使用的是docker部署的rabbitmq，看到简书的这个，镜像版本是rabbitmq:3.7.7-management。原因：延迟插件不支持mandatory=true参数，如果启用会同时收到延迟消息和路由失败消息。DirectConfig此类是配置direct交换机，及队列，绑定关系。延迟交换机测试，场景就是下单了，没付费，过期取消订单。发送消息，指定路由键为man，

背景： rabbitmq支持消息的回调，即生产者推送消息成功，消费者消费消息成功都可以进行消息的确认， 生产者配置项： 1、配置applicaiton.properties： server.port = 8888 spring.application.name=spirng-boot-rabbitmq-sender spring.rabbitmq.host=127.0.0.1 spring.rabbitmq.port=5672 spring.rabbitmq.username=gue...

一、说明 上一篇文章里，我们了解了如何保证消息被可靠投递到RabbitMQ的交换机中，但还有一些不完美的地方，试想一下，如果向RabbitMQ服务器发送一条消息，服务器确实也接收到了这条消息，于是给你返回了ACK确认消息，但服务器拿到这条消息一看，找不到路由它的队列，于是就把它丢进了垃圾桶，emmm，我猜应该属于可回收垃圾。 二、如何让消息可靠投递到队列   如果你对上面的描述还不是很清楚，那我再用代码来说明一次。   在仅开启了生产者确认机制的情况下，交换机接收到消息后，会直接给消息生产者发送确认消息，

消息的可靠性保证：保证消息在传输过程中不会出现消息丢失的情况，确保发送的消息至少被消费一次。

消息发布的可靠性 在默认的配置下，生产者发布消息的过程为，首先生产者将消息发送到交换器，然后交换器将消息路由到队列中。在这个过程中可能发生，由于路由键匹配失败，消息无法发送到绑定在交换器上的队列中。这时交换器就会丢掉这条消息（消息进入“黑洞”），但是生产者端是毫无察觉，与发送成功的返回的结果一样，也就是说无法区分消息是否真正到达RabbitMQ的。  怎么保证我们消息发布的可靠性？有以下常用几...

一、如何保证消息100%投递成功 ①保障消息成功发出 ②保障MQ节点成功接收 ③发送端收到MQ节点(Broker)确认应答 ④完善的消息进行补偿机制（因为前面可以能哪一步出现网络问题导致失败） 解决方案如下： 1、消息入库，然后发送成功后修改状态，外加定时任务轮询发送失败的消息 生产者在发送消息前，先将业务信息和要发送的消息分布入库到对应的数据库；第二步在将消息发送的MQ中；第三步是MQ接收到消息反馈给发送者；第四步监听确认接收到了消息更新消息状态； 如果步骤一都失败那就需要使用快速失败； 有一个分布式定

在本文中直接进行介绍消息的生产和消费过程；

文章目录一、背景二、原因三、解决方法四、参考资料 一、背景 使用rabbitmq-delayed-message-exchange延迟队列插件 设置Mandatory=true，消息无法路由。报错：NO_ROUTE 二、原因 官方说明 https://github.com/rabbitmq/rabbitmq-delayed-message-exchange 解读如下： Delayed messages are stored in a Mnesia table (also see Limitatio

3、Pub/Sub 订阅模式 交换机需要与队列进行绑定，绑定之后。一个消息同时被多个消费者收到。消费者收到的都是一样的消息； 代码实现;队列能自动创建，交换机不能，必须提前创建，否则会报错；交换机可以用程序来创建，后面有； 交换机类型： Fanout 广播：讲消息交给所有绑定的交换机队列；我们目前要使用这种交换机； 发布者代码 第一个参数交换机名字 其他参数和之前的一样 channel.basicPublish(“jiaohuanjiName”,"" , null , input.getBytes()

文章目录RabbitMQ的结构RabbitMQ的优点消息队中间件的缺点消息的路由实现什么是“黑洞”？如何避免“黑洞”问题？RabbitMQ的交换器种类fanout交换器direct交换器topic交换器headers交换器如何确保消息不丢失？ RabbitMQ的结构 Broker：消息队列服务器实体。 一个或多个 erlang node 的逻辑分组，且node上运行着 RabbitMQ 应用程序 Routing Key：路由关键字，exchange根据这个关键字进⾏消息投递。 Queue：消息队列载体，

1、什么是return机制？ 上篇博客rabbitMQ-生产者可靠发送-消息确认-Confirm 说了消息的生产者可靠发送，可以依靠confirm模式。但是confirm模式只保证消息成功从生产者发送到交换机，但是如果交换机没有找到queue呢？如果根据路由发送到具体的队列queue的时候，没有匹配的队列呢？这种情况confirm模式不能保证，这就得依赖return回退机制了。 return回退机制就是当交换机路由到queue的时候，没有匹配的队列，return模式可以在消息发送之后异步监听到mq的回

1、application.yml文件上，加上消息确认的配置项 server: port: 8600 spring: application: name: rabbitmq-provider rabbitmq: host: 192.168.189.131 port: 5673 username: admin password: admin ...

简介 RabbitMQ 即一个消息队列，主要是用来实现应用程序的异步和解耦，同时也能起到消息缓冲，消息分发的作用。 RabbitMQ是实现AMQP（高级消息队列协议）的消息中间件的一种，AMQP，即Advanced Message Queuing Protocol， 高级消息队列协议，是一个面向消息中间件的开放式标准应用层协，议为面向消息的中间件设计,AMQP定义了这些特性： 消息方向 消...