幂等性
问题：我们先来讲一个幂等性的问题，什么是幂等性问题？
答案：简单来说就是消息的重复消费，消费者正在消费MQ中的消息时，MQ已经把消息发送给消费者，消费者在给MQ返回ack码时网络中断，故MQ未接收到确认信息，该条消息会重新发给其他其他消费者，或指责在网络重连之后再次发送给消费者，但实际上该消费者已成功消费了该条消息，造成消费者重复消费了消息，应用场景如下：
如何解决幂等性问题？
思路：MQ消费者幂等性问题的解决可以通过判断全局唯一ID或者UUID或者通过消息ID来判断当前消息时候呗消费，每次消费消息之前线判断该ID是否被消费过。
实现方法：（2种）
唯一ID+指纹码机制（不推荐）
指纹码：我们的一些规则或者时间戳或者其他服务的信息给的唯一码，不一定是我们生成的，基本都是由我们业务规则拼接来的，但是一定保证的是唯一新，然后利用查询判断ID是否存在，优势在于实现简单拼接即可，劣势在于高并发时，单个数据库就会有写入性能的瓶颈，不推荐。
Redis原子性（推荐）
利用Redis执行setnx命令，天然具有幂等性，实现不重复消费。
优先队列
什么是优先队列呢？正在什么场景会用到优先队列呢？
顾名思义，优先队列，也就是说存储在优先队列中的消息时具有优先级区别的，正常情况下，消息执行顺序时按照发送到消息队列中的顺序来执行，优先队列在消息发送到消息队列后会按照优先级排序，然后按照新的顺序来消费消息，这样的队列叫做消息队列。
场景：假设淘宝平台需要给下单未支付的用户发短信提醒支付，那么会分大客户和小客户来优先发送，这时候就会用到优先队列来调整大小客户的任务执行顺序。
惰性队列
惰性队列会尽可能的将消息存入磁盘中，而在消费者消费到相应的消息时才会被加载到内存中，它的一个重要的设计目标是能够支持更长的队列，即支持更多的消息存储。当消费者由于各种各样的原因（比如消费者下线、宕机亦或者是由于维护而关闭等）而致使长时间内不能消费消息造成堆积时，惰性队列就很有必要了。
默认情况下，当生产者将消息发送到RabbitMQ的时候，队列中的消息会尽可能的存储在内存之中，这样可以更加快速的将消息发送给消费者。即使是持久化的消息，在被写入磁盘的同时也会在内存中驻留一份备份。当RabbitMQ需要释放内存的时候，会将内存中的消息换页至磁盘中，这个操作会耗费较长的时间，也会阻塞队列的操作，进而无法接收新的消息。虽然RabbitMQ的开发者们一直在升级相关的算法，但是效果始终不太理想，尤其是在消息量特别大的时候。
惰性队列会将接收到的消息直接存入文件系统中，而不管是持久化的或者是非持久化的，这样可以减少了内存的消耗，但是会增加I/O的使用，如果消息是持久化的，那么这样的I/O操作不可避免，惰性队列和持久化消息可谓是“最佳拍档”。注意如果惰性队列中存储的是非持久化的消息，内存的使用率会一直很稳定，但是重启之后消息一样会丢失。
队列具备两种模式：default和lazy。默认的为default模式，在3.6.0之前的版本无需做任何变更。lazy模式即为惰性队列的模式，可以通过调用channel.queueDeclare方法的时候在参数中设置，也可以通过Policy的方式设置，如果一个队列同时使用这两种方式设置的话，那么Policy的方式具备更高的优先级。如果要通过声明的方式改变已有队列的模式的话，那么只能先删除队列，然后再重新声明一个新的。
