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