RabbitMQ的题

一、如何保证RabbitMQ消息的可靠传输?

从这个图中, 可以看出, 消息可能丢失的场景以及解决⽅案:
1. ⽣产者将消息发送到 RabbitMQ失败
    a. 可能原因: ⽹络问题等
    b. 解决办法: 发送⽅确认-confirm确认模式
2. 消息在交换机中⽆法路由到指定队列:
    a. 可能原因: 代码或者配置层⾯错误, 导致消息路由失败
    b. 解决办法: 发送⽅确认-return模式
3. 消息队列⾃⾝数据丢失
    a. 可能原因: 消息到达RabbitMQ之后, RabbitMQ Server 宕机导致消息丢失.
    b. 解决办法: 持久性  开启 RabbitMQ持久化, 就是消息写⼊之后会持久化到磁盘, 如果RabbitMQ 挂了, 恢复之后会⾃动读取之前存储的数据. (极端情况下, RabbitMQ还未持久化就挂了, 可能导致少量数据丢失, 这个概率极低, 也可以通过集群的⽅式提⾼可靠性)
4. 消费者异常, 导致消息丢失
   a. 可能原因: 消息到达消费者, 还没来得及消费, 消费者宕机. 消费者逻辑有问题.
   b. 解决办法: 消息确认   RabbitMQ 提供了 消费者应答机制 来使 RabbitMQ 能够感知到消费者是否消费成功消息. 默认情况下消费者应答机制是⾃动应答的, 可以开启⼿动确认, 当消费者确认消费成功后才会删除消息, 从⽽避免消息丢失. 除此之外, 也可以配置重试机, 当消息消费异常时, 通过消息重试确保消息的可靠性

二. 死信队列的概念
死信（Dead Letter）是消息队列中的⼀种特殊消息, 它指的是那些⽆法被正常消费或处理的消息.在消息队列系统中, 如RabbitMQ, 死信队列⽤于存储这些死信消息

三. 死信的来源
1) 消息过期: 消息在队列中存活的时间超过了设定的TTL
2) 消息被拒绝: 消费者在处理消息时, 可能因为消息内容错误, 处理逻辑异常等原因拒绝处理该消息. 如果拒绝时指定不重新⼊队(requeue=false), 消息也会成为死信.
3) 队列满了: 当队列达到最⼤⻓度, ⽆法再容纳新的消息时, 新来的消息会被处理为死信.

四. 死信队列的应⽤场景
对于RabbitMQ来说, 死信队列是⼀个⾮常有⽤的特性. 它可以处理异常情况下,消息不能够被消费者正确消费⽽被置⼊死信队列中的情况, 应⽤程序可以通过消费这个死信队列中的内容来分析当时遇到的异常情况, 进⽽可以改善和优化系统.
⽐如: ⽤⼾⽀付订单之后, ⽀付系统会给订单系统返回当前订单的⽀付状态
为了保证⽀付信息不丢失, 需要使⽤到死信队列机制. 当消息消费异常时, 将消息投⼊到死信队列中, 由订单系统的其他消费者来监听这个队列, 并对数据进⾏处理(⽐如发送⼯单等,进⾏⼈⼯确认).
场景的应⽤场景还有:
• 消息重试：将死信消息重新发送到原队列或另⼀个队列进⾏重试处理.
• 消息丢弃：直接丢弃这些⽆法处理的消息，以避免它们占⽤系统资源.
• ⽇志收集：将死信消息作为⽇志收集起来，⽤于后续分析和问题定位.

五、延迟队列是⼀个特殊的队列, 消息发送之后, 并不⽴即给消费者, ⽽是等待特定的时间, 才发送给消费者.
延迟队列的应⽤场景有很多, ⽐如:
1. 订单在⼗分钟内未⽀付⾃动取消
2. ⽤⼾注册成功后, 3天后发调查问卷
3. ⽤⼾发起退款, 24⼩时后商家未处理, 则默认同意, ⾃动退款
4. ......
但RabbitMQ本⾝并没直接实现延迟队列, 通常有两种⽅法:
1. TTL+死信队列组合的⽅式
2. 使⽤官⽅提供的延迟插件实现延迟功能
⼆者对⽐:
1. 基于死信实现的延迟队列
a. 优点: 1) 灵活不需要额外的插件⽀持
b. 缺点: 1) 存在消息顺序问题 2) 需要额外的逻辑来处理死信队列的消息, 增加了系统的复杂性
2. 基于插件实现的延迟队列
a. 优点: 1) 通过插件可以直接创建延迟队列, 简化延迟消息的实现. 2) 避免了DLX的时序问题
b. 缺点: 1) 需要依赖特定的插件, 有运维⼯作 2) 只适⽤特定版本