卷土的博客

消费者由于各种原因而致使长时间不能消费消息造成堆积。比如有一百万条消息发送到mq中，消费者这时宕机了不能消费消息，造成了消息堆积。惰性队列就有必要了。正常情况下，消息保存在内存中。消费者从内存中读取消息消费，速度快。惰性队列，消息保存在磁盘中，消费者从磁盘读取消息进行消费，速度慢。

订单催付，如果此时有很多订单，一部分订单是大客户的订单，其他是小客户的订单。在给用户发送提醒支付消息的时候，就应该优先推送大客户的催付的消息。队列的消息顺序应该是先进先出，但是我们可以给队列中的每条消息设置一个优先级，这个优先级的范围是0-255，不能超过255，数据越大优先级越高。官方允许0-255之间，此处设置为10，允许优先级的范围是0-10，不要设置过大，浪费cpu与内存。

用户对同一操作发起的一次请求或多次请求的结果是一致的。方式用户重复提交。也就是消息被重复消费了。消费者在消费mq中的消息时，mq已经把消息发送给消费者，消费者在给mq返回ack时网络中断，故mq未收到确认消息，该条消息会重新发给其他消费者，或者在网络重连后再次发送给该消费者，但实际上该消费者已经成功消费了该条消息，造成消费者消费了重复的消息。

前面提到当消息发送给交换机，交换机出故障，或者队列出现故障，会反馈给生产者。如果交换机备份，将无法投递的消息发送给备份交换机，再由备份交换机给备份队列和告警队列的思路，来防止消息不丢失。之前如果创建了confirm.exhange这个交换机，需要删除后重新创建。

生产环境中由于一些不明原因，导致rabbitmq重启，在重启的期间生产者消息投递失败，导致消息丢失，需要手动处理恢复。那么如何才能进行rabbitmq的消息可靠性投递？特别是在极端的情况，rabbitmq集群不可用的时候，无法投递的消息该如何处理？

前面谈到基于死信的延迟队列，存在的问题：如果第一个消息延时时间很长，而第二个消息延时时间很短，第二个消息并不会优先得到执行。

前面所讲的延迟队列有一个不足之处，比如现在有一个需求需要延迟半个小时的消息，那么就只有添加一个新的队列。那就意味着，每新增一个不同时间需求，就会新创建一个队列。

延迟队列，队列内部是有序的，延迟队列中的元素是希望在指定时间到了以后或之前取出和处理。

【代码】18.springboot整合swagger。

正常队列中收到消息，拒绝消息并且不重新放入正常队列中，那么这个消息就成为了死信，将进入到死信队列中。所以被拒消息成为死信还需要满足一个条件就是不再重新放入正常队列中。，如果之前队列已经创建过了。那么对其做了修改后一定要删除原来的队列，让其重新创建队列。可以看出，有一条消息被拒绝了，进入了死信队列。其他消息被C1正常消费了。

队列消息的长度，超过了将进入死信队列的情况。//设置普通队列的消息长度，如果之前队列已经创建过了。那么对其做了修改后一定要删除原来的队列，让其重新创建队列。队列设置的最大长度限制后，队列有一个Lim标识。DLX表示有一个死信交换机DLK表示有一个死信routingKey可以从管理平台看出，队列消息超过六条就进入到死信队列了。需要先启动C1，让其声明好交换机和队列，然后建立他们的关系。然后停掉C1，不然消息就会被C1消费者消费掉。

死信就是。生产者将消息投递给broker或者直接到队列里，消费者从队列中取出消息进行消费。但是某些时候由于特定的原因导致queue中的某些消息无法被消费，这样的消息如果没有后续处理，就变成了死信。有死信自然就有。将不能消费的消息也就是死信放入到死信队列，后续再去处理死信队列中的消息。：为了保证订单业务的消息不丢失，需要用到死信队列机制。用户在商城下单成功并点击去支付后，在指定时间未支付时自动失效。

主题交换机比直接交换机和扇出交换机更加完美。主题交换机的routingKey不能随意写，必须满足一定的要求，必须是一个单词列表，以点号分隔开。这个单词列表不能超过255个字节。* 可以替代一个单词；# 可以替代零个或多个单词；:中间带orange的三个单词的字符串。:最后一个单词是orange的三个单词。: 第一个单词是lazy的多个单词。1.当一个队列绑定的键是，那么这个队列将接收所有数据，有点像fanout了。2.如果队列绑定的键中没有的出现，那么该队列绑定类型就是direct了。

扇出交换机的routingKey都是空串，也就是一样的。而直接类型交换机的routingKey都是不一样的。还有就是交换机的类型不一样。直接类型交换机，也叫做路由模式。通过routingKey可以做到区别的对待，可以只给队列Q1发消息，也可以只给队列Q2发消息。

前面都是发送消息到队列，交换机的参数设置为空串""，其实使用的是默认交换机。可以看出默认交换机属于直接交换机类型direct。默认交换机会路由到指定的的队列。与是通过routingkey进行绑定。之前使用无名交换机，这个routingkey默认就是队列的名称。

消息不丢失的一个重要环节。尽管它告诉rabbitmq将消息保存到磁盘，但是依然存在当消息刚准备存储到磁盘的时候，但是还没有存储完，消息还在缓存的一个间隔点。此时消息并没有真正的写入磁盘。持久性保证并不强。就是当消息真正保存到磁盘上的时候，要跟生产者说一声真的将消息保存到磁盘上了。

在之前的工作队列模式中，对于多个消费者，也就是多个工作线程采用的是轮训分发的方式消费消息。轮训分发策略并不是很好，比如两个消费者在处理任务时候，其中一个消费者处理速度快，另一个消费者处理速度慢。采用轮训分发就会造成处理速度快的消费者有很大一部分时间处于空闲状态。应该遵循能者多劳的原则。

和都可以持久化。持久化的目的就是让消息不丢失。RabbitMQ本身退出，或者由于某种原因崩溃时造成的消息丢失。RabbitMQ一旦宕机，就会造成队列和消息都丢失了。RabbitMQ重启之后，非持久化的队列和消息都不存在了。

消费者完成一个任务可能需要一段时间，如果其中一个消费者处理一个长时间的任务并且只完成了部分突然就挂掉了，会发生什么情况？RabbitMQ一旦向消费者传递了一条消息，便立即将该消息标记为删除。这种情况下，突然有个消费者挂掉了，我们将丢失正在处理的消息。以及后续发送给该消费者的消息，也无法接收到。为了保证消息在发送过程中不丢失，rabbitmq引入消息应答机制。消费者在接收到消息并且处理该消息之后，告诉rabbitmq它已经处理了，rabbitmq可以把该消息删除了。

工作队列又叫任务队列，避免立即执行资源密集型任务，而不得不等待它完成。把任务封装成消息并将其发送到队列，当有多个工作线程时，这些工作线程将一起处理这些任务。多个工作线程也就是多个消费者，采用轮训分发。

操作文件的依赖 信道channel声明队列方法详解：信道channel发送消息：生产者发送消息成功以后：可以看出队列hello中有一个消息正准备被消费。

每一个virtual host表示一个库，不同的virtual host 里面的交换机和队列是不一样的。用户admin具有/这个virtual host中所有资源的配置、写、读权限。可以在界面上添加用户，添加virtual hosts。成功登陆，并拥有virtual hosts /

安装前提，需要一个erlang语言环境。

RabbitMQ是一个消息中间件，接受并转发消息。它接收、存储和转发消息数据。

消息队列，本质是一个队列，先进先出，只不过队列中存放的内容是message而已。