你们的项目为什么要用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