RabbitMQ
你们的项目为什么要用RabbitMQ? 消息队列的作用是系统解耦、同步改异步、请求消峰,举个下订单的例子: 前端获取用户订单信息,请求后端的订单创建接口。这个接口并不直接请求订单服务,而是首先生成唯一订单编号,再组装一个订单消息并发送给RabbitMQ,然后返回唯一订单编号给前端。前端会根据唯一订单编号轮询订单状态接口,如果订单创建成功,则拉起支付界面引导用户付款。作为消费者,订单服务收到订单消息后,开始检查参数、检查库存、生成订单等等核心业务流程。 解耦体现在订单创建接口并没有直接访问订单服务,使得它不用关注订单服务接口的变化。由于不是直接调用,同步操作变成了异步操作。试想一下,订单创建状态是同步返回的,用户界面必然卡起来。由于消息队列允许消息堆积,即使大量的用户订单涌过来,订单服务依然能够稳步的处理订单消息。
保证消息不丢失
RabbitMQ提供了publisher confirm机制来避免消息发送到MQ过程中丢失。消息发送到MQ以后,会返回一个结果给发送者,表示消息是否处理成功
消息内存话
MQ默认是内存存储消息,开启持久化功能可以确保缓存在MQ中的消息不丢失。
消费者确认
RabbitMQ支持消费者确认机制,即:消费者处理消息后可以向MQ发送ack回执,MQ收到ack回执后才会删除该消息。
而SpringAMQP则允许配置三种确认模式:
- manual:手动ack,需要在业务代码结束后,调用api发送ack。
- auto:自动ack,由spring监测listener代码是否出现异常,没有异常则返回ack;抛出异常则返回nack.
- none:关闭ack,MQ假定消费者获取消息后会成功处理,因此消息投递后立即被删除
我们可以利用Spring的retry机制,在消费者出现异常时利用本地重试,设置重试次数,当次数达到了以后,如果消息依然失败,将消息投递到异常交换机,交由人工处理
消息重复消费
消息堆积
RabbitMQ如果有100万消息堆积在MQ,如何解决(消息堆积怎么解决)
当生产者发送消息的速度超过了消费者处理消息的速度,就会导致队列中的消息堆积,直到队列存储消息达到上限。之后发送的消息就会成为死信,可能会被丢弃,这就是消息堆积问题。
解决消息堆积有三种种思路:
增加更多消费者,提高消费速度
在消费者内开启线程池加快消息处理速度
扩大队列容积,提高堆积上限,采用惰性队列
惰性队列的特征如下:
接收到消息后直接存入磁盘而非内存
消费者要消费消息时才会从磁盘中读取并加载到内存
支持数百万条的消息存储
延迟队列
延迟队列:进入队列的消息会被延迟消费的队列
场景:超时订单、限时优惠、定时发布
延迟队列 =死信交换机+TTL(生存时间)
死信队列
3种情况,消息被拒绝、消息过期了、队列达到最大的长度。
当一个队列中的消息满足下列情况之一时,可以成为死信(dead letter) :
- 消费者使用basic.reject或 basic.nack声明消费失败,并且消息的requeue参数设置为false
- 消息是一个过期消息,超时无人消费
- 要投递的队列消息堆积满了,最早的消息可能成为死信
Rabbit高可用机制
- 在生产环境下,使用集群来保证高可用性
- 普通集群、镜像集群、仲裁队列
普通集群,或者叫标准集群(classic cluster),具备下列特征:
- 会在集群的各个节点间共享部分数据,包括:交换机、队列元信息。不包含队列中的消息。
- 当访问集群某节点时,如果队列不在该节点,会从数据所在节点传递到当前节点并返回
- 队列所在节点宕机,队列中的消息就会丢失
镜像集群:本质是主从模式,具备下面的特征:
- 交换机、队列、队列中的消息会在各个mq的镜像节点之间同步备份。
- 创建队列的节点被称为该队列的主节点,备份到的其它节点叫做该队列的镜像节点。
- 一个队列的主节点可能是另一个队列的镜像节点
- 所有操作都是主节点完成,然后同步给镜像节点
- 主宕机后,镜像节点会替代成新的主
仲裁队列:仲裁队列是3.8版本以后才有的新功能,用来替代镜像队列,具备下列特征:。
- 与镜像队列一样,都是主从模式,支持主从数据同步
- 使用非常简单,没有复杂的配置
- 主从同步基于Raft协议,强一致