使用RabbitMQ有什么好处?
异步处理
解耦
流量削峰
RabbitMQ 结构(如何发送消息?)
整体结构如下图所示:
结构介绍
Server:又称为broker,接受客户端连接,RabbitMQ 节点;
Connection:连接,应用程序与brokder建立网络连接;
channel:网络通道,几乎所有的操作都是在channel中进行的,是进行消息对象的通道,客户端可以建立 多个通道,每一个channel表示一个会话任务
Virtual Host:虚拟机,一个节点由若干个虚拟机组成;
Exchange:交换机,一个虚拟机由若干个交换机组成;
Queue:消息队列,和交换机通过routing key绑定
发送消息流程
生产者把生产的消息通过channel发送到Exchange上,Exchange通过绑定的router key来选择Queue,消费者监听到Queue上有新的消息,就消费调此消息;
如何保证消息不丢失?(可靠性)
首先搞清楚消息丢失会在哪些场景?其实在发送消息的每一个场景都会发生消息丢失情况:
- 生产者发送消息时,有可能没发送到MQ;
- 消息到达MQ了,但是MQ宕机,消息丢失;
- 消费者消费消息时,消费者宕机;
那么对应解决办法如下:
- 生产者发送消息确认机制,确认消息发送到MQ
- MQ开启持久化,确保消息未消费前在队列中不丢失(交换机持久化、队列持久化、消息持久化)
- 消费者确认机制
- 开启消费者失败重试机制,多次重试失败投递异常交换机
如何解决消息重复消费问题?(消息幂等性)
给每条消息设置一个唯一的标识id
其他解决方案
利用数据库唯一约束:消费数据写入数据库,可以先根据主键查询数据是否已经存在,如果已经存在了就没必要插入了。或者直接插入也没问题,因为可以利用主键的唯一性来保证数据不会重复插入,重复插入只会报错,但不会出现脏数据
还有其他解决方案,后续遇到会进行补充~~~
介绍 MQ 中延时队列?(死信交换机)
利用TTL结合死信交换机,我们实现了消息发出后,消费者延迟收到消息的效果。这种消息模式就称为延迟队列(Delay Queue)模式
延迟队列 = 死信交换机 + TTL(生存时间)
使用场景:● 延迟发送短信
● 用户下单,如果用户在15 分钟内未支付,则自动取消
● 预约工作会议,20分钟后自动通知所有参会人员
● 定时发布抖音作品
死信交换机
满足下面条件之一就被称为死信:
- 消费者拒绝消费
- 超时未消费
- 消息堆积满了,最早的消息成为死信
图解:
代码实现:
TTL
看如下代码,就是消息设置了过期时间:
延迟队列插件
需要保证 RabbitMQ 已经安装了插件,这里不展开叙述。具体可以谷歌一下
如何解决消息堆积问题?
消息堆积发生原因是什么?是因为生产者发送消息过快,而消费者不能及时消费,导致消息堆积。那么解决办法如下:
- 增加消费者进行消费
- 消费者方可以添加线程池加快消息处理速度
- 使用惰性队列,可以在MQ中保存更多消息
惰性队列特征:
接收到消息后直接存入磁盘而不是内存
消费者消费消息时才会从磁盘中读取并加载到内存
支持数百万条的消息存储
惰性队列优点:基于磁盘存储,消息上限高
没有间歇性page-out,性能稳定
惰性队列缺点:由于存储在磁盘,消息时效性会降低
性能受限于磁盘的IO
惰性队列使用:
RabbitMQ 高可用机制?(集群模式)
普通集群(不采用)
镜像集群
仲裁队列
参考链接
https://blog.csdn.net/zw791029369/article/details/109561457
https://www.bilibili.com/video/BV1yT411H7YK?p=58