怕什么真理无穷，进一寸有一寸的欢喜。即使开了一辆老掉牙的破车，只要在前行就好，偶尔吹点小风，这就是幸

视频地址在我们系统中有一个订单催付的场景，我们的客户在天猫下的订单,淘宝会及时将订单推送给我们，如果在用户设定的时间内未付款那么就会给用户推送一条短信提醒，很简单的一个功能对吧，但是，tmall商家对我们来说，肯定是要分大客户和小客户的对吧，比如像苹果，小米这样大商家一年起码能给我们创造很大的利润，所以理应当然，他们的订单必须得到优先处理，而曾经我们的后端系统是使用 redis 来存放的定时轮询，大家都知道 redis 只能用 List 做一个简简单单的消息队列，并不能实现一个优先级的场景，所以订单量大了

有了 mandatory 参数和回退消息，我们获得了对无法投递消息的感知能力，有机会在生产者的消息无法被投递时发现并处理。但有时候，我们并不知道该如何处理这些无法路由的消息，最多打个日志，然后触发报警，再来手动处理。而通过日志来处理这些无法路由的消息是很不优雅的做法，特别是当生产者所在的服务有多台机器的时候，手动复制日志会更加麻烦而且容易出错。而且设置 mandatory 参数会增加生产者的复杂性，需要添加处理这些被退回的消息的逻辑。如果既不想丢失消息，又不想增加生产者的复杂性，该怎么做呢？前面在设置死信

首先复习一下我们前面学习的发布确认，生产者将信道设置成 confirm 模式，这样就可以确定消息是否被队列接收，这样就可以在回调中进行相应的处理了。在生产环境中由于一些不明原因，导致 rabbitmq 重启，在 RabbitMQ 重启期间生产者消息投递失败，导致消息丢失，需要手动处理和恢复。于是，我们开始思考，如何才能进行 RabbitMQ 的消息可靠投递呢？特别是在这样比较极端的情况，RabbitMQ 集群不可用的时候，无法投递的消息该如何处理呢:编写配置类编写生产者编写消费者上面的环境已经搭建

前面介绍了死信队列，针对于ttl进入死信队列的情况，假如我们把前面的消费者一关闭，然后对所有的消息都进行设置过期时间，这样是不是就形成了一个延迟队列了？使用场景：比如订单超时关闭，假如我们使用定时任务，假如数据量很大的情况下肯定会存在问题，因为需要检查是否达到定时时间，这么大的数据量，肯定会很占用时间，所以这个时候使用延迟队列就比较合适了，创建SpringBoot工程，添加依赖在配置文件中添加，里面写自己的东西。下面我们实现下面这个场景编写配置类写发送消息的Controller写处理延时消息的消

视频地址先从概念解释上搞清楚这个定义，死信，顾名思义就是无法被消费的消息，字面意思可以这样理解，一般来说，producer 将消息投递到 broker 或者直接到 queue 里了，consumer 从 queue 取出消息进行消费，但某些时候由于特定的原因导致 queue 中的某些消息无法被消费，这样的消息如果没有后续的处理，就变成了死信，有死信自然就有了死信队列。应用场景:为了保证订单业务的消息数据不丢失，需要使用到 RabbitMQ 的死信队列机制，当消息消费发生异常时，将消息投入死信队列中.还有比如

视频地址之前我们学习了扇出模式和直接模式，但是他们呢只能完成广播和到指定的某一个routingkey，但是如果我们想要像类似于正则表达式那样完成匹配即可接收就不行了，那么就可以使用主题模式来完成这个需要。发送到类型是 topic 交换机的消息的 routing_key 不能随意写，必须满足一定的要求，它必须是一个单词列表，以点号分隔开。这些单词可以是任意单词，比如说：“stock.usd.nyse”, “nyse.vmw”, “quick.orange.rabbit”.这种类型的。当然这个单词列表最多不能

视频地址RabbitMQ 消息传递模型的核心思想是: 生产者生产的消息从不会直接发送到队列。实际上，通常生产者甚至都不知道这些消息传递传递到了哪些队列中。情况实际上是这样的，生产者只能将消息发送到交换机(exchange)，交换机工作的内容非常简单，一方面它接收来自生产者的消息，另一方面将它们推入队列。交换机必须确切知道如何处理收到的消息。是应该把这些消息放到特定队列还是说把他们到许多队列中还是说应该丢弃它们。这就的由交换机的类型来决定。我们前面没有指定交换机的类型的时候都是使用的默认交换机，后面我们使用

在最开始的时候我们学习到 RabbitMQ 分发消息采用的轮训分发，但是在某种场景下这种策略并不是很好，比方说有两个消费者在处理任务，其中有个消费者 1 处理任务的速度非常快，而另外一个消费者 2 处理速度却很慢，这个时候我们还是采用轮训分发的化就会到这处理速度快的这个消费者很大一部分时间处于空闲状态，而处理慢的那个消费者一直在干活，这种分配方式在这种情况下其实就不太好，但是RabbitMQ 并不知道这种情况它依然很公平的进行分发。为了避免这种情况，我们可以设置参数 channel.basicQos(1)

思考：假如我们的消费者正在处理一个任务，这个任务处理的过程中，突然这个消费者宕机了，导致这个任务没有完成，然而RabbitMQ队列却把这个任务从队列中删除了，那么这个任务就丢失了。改如何解决？为了保证消息在发送过程中不丢失，rabbitmq 引入消息应答机制，消息应答就是:消费者在接收到消息并且处理该消息之后，告诉 rabbitmq 它已经处理了，rabbitmq 可以把该消息删除了。注意消息的手动应答如果消费者由于某些原因失去连接(其通道已关闭，连接已关闭或 TCP 连接丢失)，导致消息未发送 A

首先创建一个工程首先我们需要编写生产者，产生任务程序运行之后就可以在可视化界面中看到了编写消费者程序这样消费者端就可以进行资源的消费了消费者代码生产者代码这里打开IDEA的多次运行是运行多个实例，让后我们运行两次实例，第二次把Consumer1给成Consumer2。然后运行生产者端代码可以发现消息是轮询被消费者消费的了。...