90、RabbitMQ如何确保消息发送?消息接收?

RabbitMQ如何确保消息发送?消息接收?

发送方确认机制

  • 信道需要设置为 confirm 模式,则所有在信道上发布的消息都会分配一个唯一 ID。
  • 一旦消息被投递到queue(可持久化的消息需要写入磁盘),信道会发送一个确认给生产者(包含消息唯一 ID)
  • 如果 RabbitMQ 发生内部错误从而导致消息丢失,会发送一条 nack (未确认) 消息给生产者。
  • 所有被发送的消息都将被 confirm(即 ack) 或者被nack一次。但是没有对消息被 confirm 的快慢做任何保证,并且同一条消息不会既被 confirm又被nack
  • 发送方确认模式是异步的,生产者应用程序在等待确认的同时,可以继续发送消息。当确认消息到达生产者,生产者的回调方法会被触发。
  • ConfirmCallback接口: 只确认是否正确到达 Exchange 中,成功到达则回调
  • ReturnCallback接口: 消息失败返回时回调

接收方确认机制

  • 消费者在声明队列时,可以指定noAck参数,当noAck=false时,RabbitMQ会等待消费者显式发回ack信号后才从内存(或者磁盘,持久化消息)中移去消息。否则,消息被消费后会被立即删除。
  • 消费者接收每一条消息后都必须进行确认(消息接收和消息确认是两个不同操作》。只有消费者确认了消息,RabbitMQ才能安全地把消息从队列中删除。
  • RabbitMQ不会为未ack的消息设置超时时间,它判断此消息是否需要重新投递给消费者的唯一依据是消费该消息的消费者连接是否已经断开。这么设计的原因是RabbitMQ允许消费者消费一条消息的时间可以很长。保证数据的最终一致性:
  • 如果消费者返回ack之前断开了链接,RabbitMQ 会重新分发给下一个订阅的消费者。 (可能存在消息重复消费的隐患需要去重)
相关推荐
努力的小郑2 天前
从一次分表实践谈起:我们真的需要复杂的分布式ID吗?
分布式·后端·面试
AAA修煤气灶刘哥2 天前
别让Redis「歪脖子」!一次搞定数据倾斜与请求倾斜的捉妖记
redis·分布式·后端
往事随风去3 天前
架构师必备思维:从“任务队列”到“事件广播”,彻底吃透消息队列两大设计模式
消息队列·rabbitmq
Aomnitrix3 天前
知识管理新范式——cpolar+Wiki.js打造企业级分布式知识库
开发语言·javascript·分布式
程序消消乐3 天前
Kafka 入门指南:从 0 到 1 构建你的 Kafka 知识基础入门体系
分布式·kafka
智能化咨询3 天前
Kafka架构:构建高吞吐量分布式消息系统的艺术——进阶优化与行业实践
分布式·架构·kafka
Chasing__Dreams3 天前
kafka--基础知识点--5.2--最多一次、至少一次、精确一次
分布式·kafka
在未来等你3 天前
Elasticsearch面试精讲 Day 17:查询性能调优实践
大数据·分布式·elasticsearch·搜索引擎·面试
大数据CLUB3 天前
基于spark的澳洲光伏发电站选址预测
大数据·hadoop·分布式·数据分析·spark·数据开发