你们的项目为什么要用RabbitMQ？ 消息队列的作用是系统解耦、同步改异步、请求消峰，举个下订单的例子： 前端获取用户订单信息，请求后端的订单创建接口。这个接口并不直接请求订单服务，而是首先生成唯一订单编号，再组装一个订单消息并发送给RabbitMQ，然后返回唯一订单编号给前端。前端会根据唯一订单编号轮询订单状态接口，如果订单创建成功，则拉起支付界面引导用户付款。作为消费者，订单服务收到订单消息后，开始检查参数、检查库存、生成订单等等核心业务流程。 解耦体现在订单创建接口并没有直接访问订单服务，使得它不用关注订单服务接口的变化。由于不是直接调用，同步操作变成了异步操作。试想一下，订单创建状态是同步返回的，用户界面必然卡起来。由于消息队列允许消息堆积，即使大量的用户订单涌过来，订单服务依然能够稳步的处理订单消息。

为什么非要用RabbitMQ，考虑过RocketMQ或者ActiveMQ吗？ 近些年ActiveMQ更新较少，而且没有大规模吞吐量场景的验证，就不考虑了。我们考虑过RocketMQ，无论是可用性、吞吐量、成功案例，它都很不错。我们的运维团队对RabbitMQ更熟悉，而且更看重消息的可靠性，最后选择了RabbitMQ。

采用RabbitMQ怎么避免消息丢失？

通过RabbitMQ能实现定时任务吗？ RabbitMQ并不支持设置定时消息，但是可以通过过期消息和死信队列来实现。 有2种方式设置消息的过期时间，第一种通过对队列进行设置，该队列中所有的消息都存在相同的过期时间，第二种对消息本身进行设置，那么每条消息的过期时间都不一样。如果同时使用这2种方法，那么以过期时间小的那个数值为准。当消息达到过期时间还没有被消费，那个消息就成为了一个死信消息。消费者监听死信交换器绑定的队列，就能消费到消息，做相应的业务处理。

哪几种情况会变成死信消息？ 3种情况，消息被拒绝、消息过期了、队列达到最大的长度。