为什么要使用消息队列呢？

• 解耦
• 异步
• 削峰

消息队列有哪些消息模型？

• 队列模型
• 发布/订阅模型

什么是 RabbitMQ

• 采用 AMQP 的一种消息队列技术
• 消费不需要确保提供方的存在，实现服务之间的高度解耦
  ![[Pasted image 20230912100546.png]]

RabbitMQ 的概念

• Connection：Producer/Consumer 和 Broker 的 TCP 连接
• Broker：接收和分发消息的应用
• Virtual host：把 AMQP 的基本组件划分到虚拟的分组中
• Exchange：根据分发规则，匹配表的 key 值，分发消息到队列中
• Queue：存放消息的队列，等待取走
• Channel：如果每次访问 RabbitMQ 都建立一个 Connection，消息量大时的开销很大，因此使用多线程，每个线程创建单独的 Channel 通讯，减少操作系统建立 TCP 的开销

消息基于什么传输？

• 由于 TCP 的连接和销毁开销很大
• RabbitMQ 使用信道的方式来传输数据
• 信道是建立在真实的 TCP 连接内的虚拟连接

RabbitMQ 的应用场景

• 服务间异步通信
• 顺序消费
• 定时任务
• 请求削峰

消息丢失 / 如何保证消息的可靠传输

常见的丢失原因

• 生产者发送的消息未送达 Exchange
• 消息到达 Exchange，未到达 Queue
• MQ 宕机，Queue 消息丢失
• Consumer 接收到消息，未消费就宕机

解决方案

• 生产者确认机制：给每个消息指定一个唯一的 ID，消息发送到 MQ 之后，会返回一个结果给发送者，表示消息是否处理成功
• MQ 持久化：消息写入后持久化到磁盘
• 消费者确认机制：消费者获取消息后，应该向 RabbitMQ 发送 ACK 回执，表示消息已经处理
• 失败重试机制：失败重试，达到最大重试次数，丢弃消息

消息重复消费

造成重复消费的原因

• MQ 向消费者推送信息，消费者向 MQ 返回 ACK 确认
• 但由于网络等原因，可能造成消费者向 MQ 返回的 ACK 丢失
• MQ 长时间收不到 ACK，会再次向消费者推送信息，就造成了重复消费

解决方案

• 用 Redis 记录已经消费的 message 的 id
• 当 message 被消费前先去存储中查一下消费记录
• 没有这条信息的 id 则正常消费，并返回 ACK
• 如果有，就不消费，直接返回 ACK