RabbitMQ面试题
中间件选型
为什么要使用消息队列？
异步处理 - 相比于传统的串行、并行方式，提高了系统吞吐量。
应用解耦 - 系统间通过消息通信，不用关心其他系统的处理。
流量削锋 - 可以通过消息队列长度控制请求量；可以缓解短时间内的高并发请求。
日志处理 - 解决大量日志传输。
消息通讯 - 消息队列一般都内置了高效的通信机制，因此也可以用在纯的消息通讯。比如实现点对点消息队列，或者聊天室等。
消息队列有什么优缺点？
优点：解耦、异步、削峰
解耦：
当多个系统或者模块，互相之间的调用很复杂，维护起来很麻烦。如果这些调用是不需要直接同步调用接口的，可以用 MQ 给它异步化解耦。
A 系统产生一条数据，发送到 MQ 里面去，哪个系统需要数据自己去 MQ 里面消费。如果新系统需要数据，直接从 MQ 里消费即可；如果某个系统不需要这条数据了，就取消对 MQ 消息的消费即可。这样下来，A 系统压根儿不需要去考虑要给谁发送数据，不需要维护这个代码，也不需要考虑人家是否调用成功、失败超时等情况。
异步：
A 系统接收一个请求，需要在自己本地写库，还需要在 BCD 三个系统写库，自己本地写库要 3ms，BCD 三个系统分别写库要 300ms、450ms、200ms。最终请求总延时是 3 + 300 + 450 + 200 = 953ms，接近 1s，用户感觉搞个什么东西，慢死了慢死了。用户通过浏览器发起请求。如果使用 MQ，那么 A 系统连续发送 3 条消息到 MQ 队列中，假如耗时 5ms，A 系统从接受一个请求到返回响应给用户，总时长是 3 + 5 = 8ms。
削峰：
减少高峰时期对服务器压力。
缺点：系统可用性降低、系统复杂度提高（如何保证消息不被重复消费、如何保证消息可靠性传输等）、数据一致性问题
使用场景有哪些？
异步通信：有些业务不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。
解耦：降低工程间的强依赖程度，针对异构系统进行适配。在项目启动之初来预测将来项目会碰到什么需求，是极其困难的。通过消息系统在处理过程中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口，当应用发生变化时，可以独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。
冗余：有些情况下，处理数据的过程会失败。除非数据被持久化，否则将造成丢失。消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的”插入-获取-删除”范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。
扩展性：因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的，只要另外增加处理过程即可。不需要改变代码、不需要调节参数。便于分布式扩容。
过载保护：在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量无法提取预知；如果以为了能处理这类瞬间峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。
可恢复性：系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。
顺序保证：在大多使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。
缓冲：在任何重要的系统中，都会有需要不同的处理时间的元素。消息队列通过一个缓冲层来帮助任务最高效率的执行，该缓冲有助于控制和优化数据流经过系统的速度。以调节系统响应时间。
数据流处理：分布式系统产生的海量数据流，如：业务日志、监控数据、用户行为等，针对这些数据流进行实时或批量采集汇总，然后进行大数据分析是当前互联网的必备技术，通过消息队列完成此类数据收集是最好的选择。
消息中间件常用协议
AMQP协议：AMQP即Advanced Message Queuing Protocol,一个提供统一消息服务的应用层标准高级消息队列协议,是应用层协议的一个开放标准,为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品，不同开发语言等条件的限制。
优点：可靠、通用
MQTT协议：MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）是IBM开发的一个即时通讯协议，有可能成为物联网的重要组成部分。该协议支持所有平台，几乎可以把所有联网物品和外部连接起来，被用来当做传感器和致动器（比如通过Twitter让房屋联网）的通信协议。
优点：格式简洁、占用带宽小、移动端通信、PUSH、嵌入式系统
STOMP协议：STOMP（Streaming Text Orientated Message Protocol）是流文本定向消息协议，是一种为MOM(Message Oriented Middleware，面向消息的中间件)设计的简单文本协议。STOMP提供一个可互操作的连接格式，允许客户端与任意STOMP消息代理（Broker）进行交互。
优点：命令模式（非topic\queue模式）
XMPP协议：XMPP（可扩展消息处理现场协议，Extensible Messaging and Presence Protocol）是基于可扩展标记语言（XML）的协议，多用于即时消息（IM）以及在线现场探测。适用于服务器之间的准即时操作。核心是基于XML流传输，这个协议可能最终允许因特网用户向因特网上的其他任何人发送即时消息，即使其操作系统和浏览器不同。
优点：通用公开、兼容性强、可扩展、安全性高，但XML编码格式占用带宽大
其他基于TCP/IP自定义的协议：有些特殊框架（如：redis、kafka、zeroMq等）根据自身需要未严格遵循MQ规范，而是基于TCP\IP自行封装了一套协议，通过网络socket接口进行传输，实现了MQ的功能。
消息中间件对比
一般业务系统要引入MQ，最早大家都用ActiveMQ，但现在用的不多了。没有经过大规模吞吐场景的验证，社区也不活跃，不推荐再使用。
后来大家开始用rabbitMQ，但是它是使用erlang语言开发的，如果不精通erlang，对公司而言，几乎处于不可控的状态，但其是开源的，社区活跃度高，拥有比较稳定的支持。
现在越来越多的公司开始使用RocketMQ，但是要小心被抛弃的风险。如果公司有实力自己去维护开发，推荐使用。否则还是选择RabbitMQ。
如果实在大数据的实时计算、日志采集等领域，用kafka是业界标准。
所以，对于中小型公司，技术实力一般的，应该用RabbitMQ，对于大公司，基础架构研发能力强大的，推荐使用RocketMQ。
AMQP模型
Server(broker): 接受客户端连接，实现AMQP消息队列和路由功能的进程，可以理解为邮局。
Virtual Host:其实是一个虚拟概念，类似于权限控制组，一个Virtual Host里面可以有若干个Exchange和Queue，当多个不同的用户使用同一个RabbitMQ server提供的服务时，可以划分出多个vhost，每个用户在自己的vhost创建exchange／queue等，就好比于tomcat中webapps目录下可以部署多个web项目。
Exchange:接受生产者发送的消息，并根据Binding规则将消息路由给服务器中的队列，就好比邮递员。
Message Queue：消息队列，用于存储还未被消费者消费的消息，就好比于邮箱。
Message: 由Header和Body组成，Header是由生产者添加的各种属性的集合，包括Message是否被持久化、由哪个Message Queue接受、优先级是多少等，就好比于邮箱里面的信件。而Body是真正需要传输的APP数据，就像信件里面的信纸。
Binding:Binding联系了Exchange与Message Queue。Exchange在与多个Message Queue发生Binding后会生成一张路由表，路由表中存储着Message Queue所需消息的限制条件即Binding Key。当Exchange收到Message时会解析其Header得到Routing Key，Exchange根据Routing Key与Exchange Type将Message路由到Message Queue。Binding Key由Consumer在Binding Exchange与Message Queue时指定，而Routing Key由Producer发送Message时指定，两者的匹配方式由Exchange Type决定，就好比于邮件上面的地址。
Connection:连接，对于RabbitMQ而言，其实就是一个位于客户端和Broker之间的TCP连接。
Channel:信道，仅仅创建了客户端到Broker之间的连接后，客户端还是不能发送消息的。需要为每一个Connection创建Channel，AMQP协议规定只有通过Channel才能执行AMQP的命令。一个Connection可以包含多个Channel。之所以需要Channel，是因为TCP连接的建立和释放都是十分昂贵的，如果一个客户端每一个线程都需要与Broker交互，如果每一个线程都建立一个TCP连接，暂且不考虑TCP连接是否浪费，就算操作系统也无法承受每秒建立如此多的TCP连接，可以简单的理解为线程池中的一个个线程。
实现原理
RabbitMQ基本概念有哪些？
Broker： 简单来说就是消息队列服务器实体
Exchange： 消息交换机，它指定消息按什么规则，路由到哪个队列
Queue： 消息队列载体，每个消息都会被投入到一个或多个队列
Binding： 绑定，它的作用就是把exchange和queue按照路由规则绑定起来
Routing Key： 路由关键字，exchange根据这个关键字进行消息投递
VHost： vhost 可以理解为虚拟 broker ，即 mini-RabbitMQ server。其内部均含有独立的 queue、exchange 和 binding 等，但最最重要的是，其拥有独立的权限系统，可以做到 vhost 范围的用户控制。当然，从 RabbitMQ 的全局角度，vhost 可以作为不同权限隔离的手段（一个典型的例子就是不同的应用可以跑在不同的 vhost 中）。
Producer： 消息生产者，就是投递消息的程序
Consumer： 消息消费者，就是接受消息的程序
Channel： 消息通道，在客户端的每个连接里，可建立多个channel，每个channel代表一个会话任务
由Exchange、Queue、RoutingKey三个才能决定一个从Exchange到Queue的唯一的线路。
RabbitMQ交换机有哪几种？
参考链接
fanout：广播模式 队列直接绑定该交换机（不需要指定routing key）
direct：消息路由到那些binding key与routing key完全匹配的Queue中
topic： 前面提到的direct规则是严格意义上的匹配，换言之Routing Key必须与Binding Key相匹配的时候才将消息传送给Queue，那么topic这个规则就是模糊匹配，可以通过通配符满足一部分规则就可以传送。
headers headers类型的Exchange不依赖于routing key与binding key的匹配规则来路由消息，而是根据发送的消息内容中的headers属性进行匹配。而是根据发送的消息内容中的headers属性进行匹配。
RabbitMQ有几种工作模式?
simple模式（即最简单的收发模式）
一个生产者，一个消费者
消息的消费者(consumer) 监听 消息队列,如果队列中有消息,就消费掉,消 息被拿走后,自动从队列中删除(隐患 消息可能没有被消费者正确处理,已经从队列中消失了,造成消息的丢失，这里可以设置成手动的ack,但如果设置成手动ack，处理完后要及时发送ack消息给队列，否则会造成内存溢出)。
work工作模式(资源的竞争)
一个生产者，多个消费者，每个消费者获取到的消息唯一。
消息产生者将消息放入队列消费者可以有多个,消费者1,消费者2同时监听同一个队列,消息被消费。C1 C2共同争抢当前的消息队列内容,谁先拿到谁负责消费消息(隐患：高并发情况下,默认会产生某一个消息被多个消费者共同使用,可以设置一个开关(syncronize) 保证一条消息只能被一个消费者使用)。
publish/subscribe发布订阅(共享资源)
一个生产者发送的消息会被多个消费者获取
生产者将消息发给broker，由交换机将消息转发到绑定此交换机的每个队列，每个绑定交换机的队列都将接收到消息。
routing路由模式
发送消息到交换机并且要指定路由key ，消费者将队列绑定到交换机时需要指定路由key
业务场景:error 通知;exception错误通知的功能;客户通知：利用key路由,可以将程序中的错误封装成消息传入到消息队列中,开发者可以自定义消费者,实时接收错误;
topic 主题模式(路由模式的一种)
将路由键和某模式进行匹配，此时队列需要绑定在一个模式上，“#”匹配一个词或多个词，“*”只匹配一个词
交换机根据key的规则模糊匹配到对应的队列,由队列的监听消费者接收消息消费
63 在我的理解看来就是routing查询的一种模糊匹配，就类似sql的模糊查询方式
RabbitMQ怎么实现延迟消息队列？
通过Rabbitmq本身队列的特性来实现，需要使用Rabbitmq的死信交换机（Exchange）和消息的存活时间TTL（Time To Live）
在rabbitmq 3.5.7及以上的版本提供了一个插件（rabbitmq-delayed-message-exchange）来实现延迟队列功能。同时插件依赖Erlang/OPT 18.0及以上
如果不使用插件，延迟消息的延迟时间是依赖于Queue1的x-message-ttl的，也就是说，需要支持多少种延迟的时间，就得提前设置好多少个无消费类的Queue，而且由于转发绑定的Queue2需要配到交换机中，比较死板，而真实的业务中消费类肯定是不一样的
若想不借助插件实现rabbitMQ的延迟消息，实际就是利用一个没有消费者的Queue1，等待消息过期后，通过交换机转发到Queue2来进行消费，消息的延迟时间就是消息在Queue1中的存活时间
RabbitMQ消息基于什么传输？
由于TCP连接的创建和销毁开销较大，且并发数受系统资源限制，会造成性能瓶颈。RabbitMQ使用信道的方式来传输数据。信道是建立在真实的TCP连接内的虚拟连接，且每条TCP连接上的信道数量没有限制。
信道是一个类似于NIO（一种TCP多路复用技术）的技术：在RabbitMQ中每个生产者、消费者线程各把持一个信道，多个信道复用了同一个TCP 连接。当每个信道的流量不是很大时，复用单连接可以在产生性能瓶颈的情况下有效地节 TCP 连接资源。当信道本身的流量很大时，就会开辟多连接，将这些信道均摊到这些连接中。
RabbitMQ消息如何分发？
循环分发：默认情况下，RabbitMQ 会顺序的分发每个Message。当每个收到ack后，会将该Message删除，然后将下一个Message分发到下一个Consumer。这种分发方式叫做round-robin。
默认状态下，RabbitMQ将第n个Message分发给第n个Consumer。当然n是取余后的。它不管Consumer是否还有unacked Message，只是按照这个默认机制进行分发。那么如果有个Consumer工作比较重，那么就会导致有的Consumer基本没事可做，有的Consumer却是毫无休息的机会。
那么，RabbitMQ是如何处理这种问题呢？
通过 basic.qos 方法设置prefetch_count=1。这样RabbitMQ就会使得每个Consumer在同一个时间点最多处理一个Message。换句话说，在接收到该Consumer的ack前，他它不会将新的Message分发给它。
这种方法可能会导致queue满。当然，这种情况下你可能需要添加更多的Consumer，或者创建更多的virtualHost来细化你的设计。
RabbitMQ消息怎么路由？
从概念上来说，消息路由必须有三部分：交换器、路由、绑定。生产者把消息发布到交换器上；绑定决定了消息如何从路由器路由到特定的队列；消息最终到达队列，并被消费者接收。
消息发布到交换器时，消息将拥有一个路由键（routing key），在消息创建时设定。
通过队列路由键，可以把队列绑定到交换器上。
消息到达交换器后，RabbitMQ会将消息的路由键与队列的路由键进行匹配（针对不同的交换器有不同的路由规则）。如果能够匹配到队列，则消息会投递到相应队列中；如果不能匹配到任何队列，消息将进入 “黑洞”。
常用的交换器主要分为一下三种：
direct：如果路由键完全匹配，消息就被投递到相应的队列
fanout：如果交换器收到消息，将会广播到所有绑定的队列上
topic：可以使来自不同源头的消息能够到达同一个队列。 使用topic交换器时，可以使用通配符，比如：“*” 匹配特定位置的任意文本， “.” 把路由键分为了几部分，“#” 匹配所有规则等。特别注意：发往topic交换器的消息不能随意的设置选择键（routing_key），必须是由"."隔开的一系列的标识符组成。
常见问题
如何保证消息的消费顺序？
一个queue，有多个consumer去消费，这样就会造成顺序的错误，consumer从MQ里面读取数据是有序的，但是每个consumer的执行时间是不固定的，无法保证先读到消息的consumer一定先完成操作，这样就会出现消息并没有按照顺序执行，造成数据顺序错误。
一个queue对应一个consumer，但是consumer里面进行了多线程消费，这样也会造成消息消费顺序错误。
拆分多个queue，每个queue一个consumer，就是多一些queue而已，确实是麻烦点；这样也会造成吞吐量下降，可以在消费者内部采用多线程的方式取消费。
或者就一个queue但是对应一个consumer，然后这个consumer内部用内存队列做排队，然后分发给底层不同的worker来处理
使用排他队列
如何保证消息不被重复消费？
参考文档
1.幂等性
幂等（idempotent、idempotence）是一个数学与计算机学概念，常见于抽象代数中。
在编程中一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。幂等函数，或幂等方法，是指可以使用相同参数重复执行，并能获得相同结果的函数。这些函数不会影响系统状态，也不用担心重复执行会对系统造成改变。例如，“setTrue()”函数就是一个幂等函数,无论多次执行，其结果都是一样的.更复杂的操作幂等保证是利用唯一交易号(流水号)实现.
简单来说，幂等性就是一个数据或者一个请求，给你重复来了多次，你得确保对应的数据是不会改变的，不能出错。
2.出现重复消费场景
（1）首先，比如rabbitmq、rocketmq、kafka，都有可能会出现消息重复消费的问题。因为这个问题通常不是由mq来保证的，而是消费方自己来保证的。
（2）举例kafka来说明重复消费问题
kafka有一个叫做offset的概念，就是每个消息写进去，都有一个offset代表他的序号，然后consumer消费了数据之后，每隔一段时间，会把自己消费过的消息的offset提交一下，代表我已经消费过了，下次就算重启，kafka就会让消费者从上次消费到的offset来继续消费。
但是万事总有例外，如果consumer消费了数据，还没来得及发送自己已经消费的消息的offset就挂了，那么重启之后就会收到重复的数据。
3.保证幂等性(重复消费)
要保证消息的幂等性，这个要结合业务的类型来进行处理。下面提供几个思路供参考：
（1）、可在内存中维护一个set，只要从消息队列里面获取到一个消息，先查询这个消息在不在set里面，如果在表示已消费过，直接丢弃；如果不在，则在消费后将其加入set当中。
（2）、如何要写数据库，可以拿唯一键先去数据库查询一下，如果不存在在写，如果存在直接更新或者丢弃消息。
（3）、如果是写redis那没有问题，每次都是set，天然的幂等性。
（4）、让生产者发送消息时，每条消息加一个全局的唯一id，然后消费时，将该id保存到redis里面。消费时先去redis里面查一下有么有，没有再消费。
（5）、数据库操作可以设置唯一键，防止重复数据的插入，这样插入只会报错而不会插入重复数据。
如何保证RabbitMQ消息的可靠传输？
主流做法是
发送消息前，先将消息持久化到本地(比如数据库)，防止消息发送失败时，再次发送找不到原来的消息
设置发送方确认模式
发送消息后，将消息的状态存入数据库并设置为发送中
发送端设定签收超时时间并监听 RabbitMQ 看消费端是否有签收
如果监听到签收，则将该消息的状态改为投递成功，否则一直等待直到超时
设置补偿机制：起一个定时任务，每隔一段时间，从数据库中找出状态为发送中且时间超时的消息，重新投递
如果多次重投后依然失败，就需要人工去处理
数据的丢失问题，可能出现在生产者、MQ、消费者中：
如何确保消息正确地发送至RabbitMQ？
将 channel 设置成 confirm 模式（发送方确认模式），则所有在 channel
上发布的消息都会被指派一个唯一的ID。一旦消息被投递到目的队列后，或者消息被写入磁盘后（可持久化的消息），信道会发送一个确认给生产者（包含消息唯一ID）。
如果RabbitMQ发生内部错误从而导致消息丢失，会发送一条nack（not acknowledged，未确认）消息。
发送方确认模式是异步的，生产者应用程序在等待确认的同时，可以继续发送消息。当确认消息到达生产者应用程序，生产者应用程序的回调方法就会被触发来处理确认消息
如何确保消息接收方消费了消息？
消费方接收每一条消息后都必须在消费完之后进行手动确认（消息接收和消息确认是两个不同操作）消费端确认之后，RabbitMQ会把消息从队列中删除
RabbitMQ仅通过消费端的连接中断来确认是否需要重新发送消息。也就是说，只要连接不中断，RabbitMQ给了消费端足够长的时间来处理消息。保证数据的最终一致性；
下面罗列几种特殊情况：
如果消费者接收到消息，在确认之前断开了连接或取消订阅，RabbitMQ会认为消息没有被分发，然后重新分发给下一个订阅的消费者。（可能存在消息重复消费的隐患，需要去重）
如果消费者接收到消息却没有确认消息，连接也未断开，则RabbitMQ认为该消费者繁忙，将不会给该消费者分发更多的消息。
如何避免消息重复投递或重复消费？
避免消息重复投递：在消息生产时，MQ内部针对每条生产者发送的消息生成一个inner-msg-id，作为去重的依据（消息投递失败并重传），避免重复的消息进入队列；
避免消息重复消费：
在消息消费时，要求消息体中必须要有一个唯一Id（对于同一业务全局唯一，如支付ID、订单ID、帖子ID等）作为去重的依据，避免同一条消息被重复消费
消费消息接口做幂等处理
RabbitMQ如何持久化？
RabbitMQ 持久化包含3个部分
exchange 持久化，在声明时指定 durable 为 true
queue 持久化，在声明时指定 durable 为 true
message 持久化，在投递时指定 delivery_mode=2（1是非持久化）
如果将所有的消息都进行持久化操作，这样会严重影响 RabbitMQ 的性能。写入磁盘的速度可比写入内存的速度要慢很多。所以需要在可靠性和吞吐量之间做权衡。
将 exchange、queue 和 message 都进行持久化操作后，也不能保证消息一定不会丢失，消息存入RabbitMQ 之后，还需要一段时间才能存入硬盘。RabbitMQ 并不会为每条消息都进行同步存盘，如果在这段时间，服务器宕机或者重启，消息还没来得及保存到磁盘当中，就会丢失。对于这种情况，可以引入 RabiitMQ 镜像队列机制（一种高可用方案）。
如何保证高可用的RabbitMQ 的集群
普通集群模式，意思就是在多台机器上启动多个 RabbitMQ 实例，每个机器启动一个。你创建的 queue，只会放在一个 RabbitMQ 实例上，但是每个实例都同步 queue 的元数据（元数据可以认为是 queue 的一些配置信息，通过元数据，可以找到 queue 所在实例）。你消费的时候，实际上如果连接到了另外一个实例，那么那个实例会从 queue 所在实例上拉取数据过来。这方案主要是提高吞吐量的，就是说让集群中多个节点来服务某个 queue 的读写操作。
镜像集群模式：这种模式，才是所谓的 RabbitMQ 的高可用模式。跟普通集群模式不一样的是，在镜像集群模式下，你创建的 queue，无论元数据还是 queue 里的消息都会存在于多个实例上，就是说，每个 RabbitMQ 节点都有这个 queue 的一个完整镜像，包含 queue 的全部数据的意思。然后每次你写消息到 queue 的时候，都会自动把消息同步到多个实例的 queue 上。RabbitMQ 有很好的管理控制台，就是在后台新增一个策略，这个策略是镜像集群模式的策略，指定的时候是可以要求数据同步到所有节点的，也可以要求同步到指定数量的节点，再次创建 queue 的时候，应用这个策略，就会自动将数据同步到其他的节点上去了。这样的话，好处在于，你任何一个机器宕机了，没事儿，其它机器（节点）还包含了这个 queue 的完整数据，别的 consumer 都可以到其它节点上去消费数据。坏处在于，第一，这个性能开销也太大了吧，消息需要同步到所有机器上，导致网络带宽压力和消耗很重！RabbitMQ 一个 queue 的数据都是放在一个节点里的，镜像集群下，也是每个节点都放这个 queue 的完整数据。
消息积压了怎么办？
参考文档
大量消息在mq里积压了几个小时了还没解决：
先修复consumer的问题，确保其恢复消费速度，然后将现有consumer都停掉。
临时建立好原先10倍或者20倍的queue数量(新建一个topic，partition是原来的10倍)。
然后写一个临时分发消息的consumer程序，这个程序部署上去消费积压的消息，消费之后不做耗时处理，直接均匀轮询写入临时建好分10数量的queue里面。
紧接着征用10倍的机器来部署consumer，每一批consumer消费一个临时queue的消息。
这种做法相当于临时将queue资源和consumer资源扩大10倍，以正常速度的10倍来消费消息。
等快速消费完了之后，恢复原来的部署架构，重新用原来的consumer机器来消费消息。
消息设置了过期时间，过期就丢了怎么办：
批量重导：在流量低峰期(比如夜深人静时)，写一个程序，手动去查询丢失的那部分数据，然后将消息重新发送到mq里面，把丢失的数据重新补回来。
积压消息长时间没有处理，mq放不下了怎么办：
丢弃+批量重导：首先，临时写个程序，连接到mq里面消费数据，收到消息之后直接将其丢弃，快速消费掉积压的消息，降低MQ的压力，然后走第二种方案，在晚上夜深人静时去手动查询重导丢失的这部分数据。
设计MQ思路
参考文档
场景：解耦/最终一致性/广播/错峰流控
使用技巧
参考文档
队列属性
queue ： 队列的名字
durable ： 为true表示队列中数据持久化到磁盘，可以防止mq宕机重启数据丢失
exclusive ： 为true表示排他性，只允许一个当前连接访问该队列，当前已连接就不允许新的连接进入否则报错，当连接断开当前队列会销毁
autoDelete ： 为true表示自动删除，当没有Connection连接到队列的时候，会自动删除
arguments ： 这个参数用来添加一些额外参数的，比如添加x-message-ttl为5000，则表示消息超过5秒没被处理就会超时过期；x-expires设置120000表示队列在2分钟内没被消费则被删除；x-max-length,x-max-length-bytes表示传送数据的最大长度和字节数x-dead-letter-exchange，x-dead-letter-routing-key表示死信交换机和死信路由，放在需要过期或处理失败的队列属性中，这些数据会转发到死信队列存储起来，创建普通的交换机和队列绑定，把交换机名填到x-dead-letter-exchange的值，填写路由键要符合死信队列的路由键；x-max-priority，表示设置优先级，范围为0~255，只有当消息堆积的时候，这个优先级才有意义，数字越大优先级越高；x-queue-mode当为lazy，表示惰性队列，3.6.0之后才被引入的概念，相比默认的模式，惰性队列模式会将生产者产生的消息直接存到磁盘中，这当然会增加IO开销，但适合应对大量消息堆积的情况；因为当大量消息堆积时，内存也不够存放，会将消息转存到磁盘，这个过程也是比较耗时且过程中不能接收新的消息。如果需要将普通队列转换成惰性队列需要将原来的队列删除，重新创建个惰性队列绑定。
交换机属性
exchange ： 交换机名称
type ： 交换机类型
durable ： 持久化，同队列
autoDelete ： 是否自动删除，同队列
internal ： 若为true，表示这个exchange不可以被client用来推送消息，仅用来进行exchange和exchange之间的绑定。
arguments ： 额外参数，目前只有个alternate-exchange，表示当生产者发送消息到这个交换机，路由不到该交换机的队列，则会尝试这个参数指定的交换机进行路由，若路由键匹配，则路由到alternate-exchange指定的队列，相当于转发了，刚好和上一个参数internal配合，若不想本交换机起到路由队列的作用，可以设置internal为true，把消息都转发到alternate-exchange指定的交换机，由该交换机来路由指定队列，
