@@ -1,58 +0,0 @@ RabbitMQ问题 - 防止数据丢失(补充) | 凤凰涅槃进阶之路

RabbitMQ问题 - 防止数据丢失(补充)

Abel sun2022年12月24日
约 620 字大约 2 分钟

RabbitMQ问题 - 防止数据丢失(补充)

1. 消息可靠传输

消息可靠传输 一般是业务系统接入消息中间件首要考虑的问题,一般消息中间件的消息传输保障分为三个层级:

  • At most once:最多一次。消息可能会丢失,但绝不会重复传输
  • At least once:最少一次。消息绝不会丢失,但可能重复传输
  • Exactly once:恰好一次。每条消息肯定会被传输一次且仅传输一次。

RabbitMQ 支持 「最多一次」和「最少一次」,不支持恰好一次

2. 最少一次投递考虑点

最少一次投递实现需要考虑以下几个方面:

  • 消息生产者需要开启事物机制或 publisher confirm 机制。确保消息传输到 RabbitMQ 中
  • 消息生产者需要配合使用 mandatory 参数或则备份交换器来 确保消息 能够从交换器路 由到队列中,进而能够保存而不被丢弃
  • 消息和队列都需要持久化处理,确保消息不会在 RabbitMQ 遇到异常情况时丢失。
  • 消费者在消费小时时,需要将 autoAck 设置为 fasle,手动进行 ack

3. 最多一次投递考虑点

最多一次,无需考虑。

4. 恰好一次(RabbitMQ无法保障)。

  • 考虑一种情况,来说明为什么无法保障:

    消费者在 消费完一条消息后,向 RabbitMQ 发送确认 Basic.Ack 命令,此时某种原因(网络断开等)导致 RabbitMQ 并没有收到这个确认命令。此时 RabbitMQ 不会将此条消息标记删除。在 重新建立连接后,还会消费到这一条消息,这就造成了 重复消费

  • 再来看一种情况:

    生产者使用 publisher confirm 机制,发送一条消息等待 RabbitMQ 返回确认通知,此时网络断开,生产者捕获到异常情况,为了确保消息可靠性选择重新发送,这样 RabbitMQ 中就有两条同样的消息。消费时就相当于重复消费。

总结起来,发生在业务系统与 RabbitMQ 交互网络连接方面。所以目前大多数主流的消息中间件都没有消息去重机制,来保障「恰好一次」。去重一般是在客户端实现,比如引入 GUID(Globally Unique Identifier)概念

参考文章

消息传输保障open in new window

评论
  • 按正序
  • 按倒序
  • 按热度
Powered by Waline v2.9.1