-
你们的项目为什么要用RabbitMQ？
消息队列的作用是系统解耦、同步改异步、请求消峰，举个下订单的例子：
前端获取用户订单信息，请求后端的订单创建接口。这个接口并不直接请求订单服务，而是首先生成唯一订单编号，再组装一个订单消息并发送给RabbitMQ，然后返回唯一订单编号给前端。前端会根据唯一订单编号轮询订单状态接口，如果订单创建成功，则拉起支付界面引导用户付款。作为消费者，订单服务收到订单消息后，开始检查参数、检查库存、生成订单等等核心业务流程。
解耦体现在订单创建接口并没有直接访问订单服务，使得它不用关注订单服务接口的变化。由于不是直接调用，同步操作变成了异步操作。试想一下，订单创建状态是同步返回的，用户界面必然卡起来。由于消息队列允许消息堆积，即使大量的用户订单涌过来，订单服务依然能够稳步的处理订单消息。 -
为什么非要用RabbitMQ，考虑过RocketMQ或者ActiveMQ吗？
近些年ActiveMQ更新较少，而且没有大规模吞吐量场景的验证，就不考虑了。我们考虑过RocketMQ，无论是可用性、吞吐量、成功案例，它都很不错。我们的运维团队对RabbitMQ更熟悉，而且更看重消息的可靠性，最后选择了RabbitMQ。 -
采用RabbitMQ怎么避免消息丢失？
- 生产者丢失消息：RabbitMQ提供transaction和confirm模式来确保生产者不丢消息。开启事务channel.txSelect()，然后发送消息，如果发送过程中出现什么异常，事务就会回滚channel.txRollback()，如果发送成功则提交事务channel.txCommit()。但是这种方式会导致吞吐量下降。confirm模式用的居多：一旦channel进入confirm模式，所有在该信道上发布的消息都将会被指派一个唯一的ID（从1开始），一旦消息被投递到所有匹配的队列之后；rabbitMQ就会发送一个ACK给生产者（包含消息的唯一ID），这就使得生产者知道消息已经正确到达目的队列了；如果rabbitMQ没能处理该消息，则会发送一个Nack消息给生产者，生产者可以重试。
- 消息列表丢失消息：开启持久化磁盘的配置
- 消费者丢失消息：处理消息成功后，手动回复确认消息。
-
通过RabbitMQ能实现定时任务吗？
RabbitMQ并不支持设置定时消息，但是可以通过过期消息和死信队列来实现。
有2种方式设置消息的过期时间，第一种通过对队列进行设置，该队列中所有的消息都存在相同的过期时间，第二种对消息本身进行设置，那么每条消息的过期时间都不一样。如果同时使用这2种方法，那么以过期时间小的那个数值为准。当消息达到过期时间还没有被消费，那个消息就成为了一个死信消息。消费者监听死信交换器绑定的队列，就能消费到消息，做相应的业务处理。 -
哪几种情况会变成死信消息？
3种情况，消息被拒绝、消息过期了、队列达到最大的长度。
参考(部分摘抄的文字版权属于原作者)：
https://www.cnblogs.com/woadmin/p/10537174.html
https://blog.csdn.net/jerryDzan/article/details/89183625
鸡汤：不要装逼，别人都看得出来。
相关文章
