rabbitmq.“消费端确认收到”和“推送者确认”(1)

本文介绍了RabbitMQ中消息确认机制的基本概念,包括消费者确认和发布者确认,并详细阐述了投递标签的作用及其使用方式。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

前序

  使用诸如rabbitmq一类的系统作为消息服务,实际中基本都是分布式系统。由于发送协议无法保证信息送达到伙伴的手里,也没法保证伙伴成功的处理这些消息。所以需要一种“确认机制”来确认传输和信息处理过程的状态。RabbitMQ的下的多个协议都有支持这个特性。本文基于AMQP 0-9-1进行介绍,但是理念也适用于其他类似的协议。

  在“订阅者/消费者”到RabbitMQ服务器的"传输成功与否确认"已知AMQP 0-9-1有涵盖。从broker(消息队列服务器)到consumers(消息发布者)是扩展协议,被称之为“Publisher Confirm.

        所有的功能都是收到TCP协议的启发。这是从publishers到RabbitMQ节点,RabbitMQ节点到consumers可靠运作的保证。

 

投递成功与否确认

    当 RabbitMQ 向消费端传送了一则消息,它需要什么情况下判定消息发送成功了。 什么样的处理的逻辑是最好的这依赖于系统。所以,这主要是一种应用决策。在AMQP 0-9-1,视为成功的条件是当消费端通过basic.consume方法注册,或者通过basic.get,消息被拉取得时候。所以投递标签的作用域是channel。

投递标识:投递标识标签

    在我们进入主题之前,我们先解释“投递”如何被标识(和确认各自的投资结果)。当有消费端(订阅者)注册的时候,RabbitMQ 将用basic.delivermethod函数将信息投递出去。这个函数携带一个“投递标签”,这个标签在一个channel上是唯一的。

    投递标签是客户端库提供的单调增长的整数。客户端确认投递结果的时候回携带一个标签参数。

    因为投递标签的作用域是channel,需要在获取消息的channel上确认投递结果。如果确认信息来自不同的channel则会报“位置标签”的协议信息并关闭channel。

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

原文:

Introduction

Systems that use a messaging broker such as RabbitMQ are bydefinition distributed. Since protocol methods (messages) sentare not guaranteed to reach the peer or be successfully processedby it, both publishers and consumers need a mechanism fordelivery and processing confirmation. Several messagingprotocols supported by RabbitMQ provide such features.This guide covers the features in AMQP 0-9-1 but the ideais largely the same in other protocols (STOMP, MQTT, et cetera).

Delivery processing acknowledgements from consumers to RabbitMQare known as acknowledgements in AMQP 0-9-1 parlance; brokeracknowledgements to publishers are a protocol extension calledpublisher confirms.

Both features build on the same idea and are inspired by TCP.They are essential for reliable delivery both from publishersto RabbitMQ nodes and from RabbitMQ nodes to consumers.

 

(Consumer) Delivery Acknowledgements

When RabbitMQ delivers a message to a consumer, it needs to know when to consider the message to be successfully sent. What kind of logic is optimal depends on the system. It is therefore primarily an application decision. In AMQP 0-9-1 it is made when a consumer is registered using the basic.consume method or a message is fetched on demand with the basic.get method.

If you prefer a more example-oriented and step-by-step material, consumer acknowledgements arealso covered in RabbitMQ tutorial #2.

Delivery Identifiers: Delivery Tags

Before we proceed to discuss other topics it is important toexplain how deliveries are identified (and acknowledgementsindicate their respective deliveries). When a consumer(subscription) is registered, messages will be delivered(pushed) by RabbitMQ using the basic.delivermethod. The method carries a delivery tag, whichuniquely identifies the delivery on a channel. Delivery tags aretherefore scoped per channel.

Delivery tags are monotonically growing positiveintegers and are presented as such by client libraries.Client library methods that acknowledge deliveries take a delivery tagas an argument.

Because delivery tags are scoped per channel, deliveries must beacknowledged on the same channel they were received on. Acknowledgingon a different channel will result in an "unknown delivery tag" protocolexception and close the channel.

 

 

 

### 回答1: 是的,如果有其他消费者订阅了当前队列并且等待接收消息RabbitMQ会将未确认消息推送给其他消费者。这是因为RabbitMQ会在队列中保留未确认消息,直到得到消费者的确认或达到超时时间。如果超时时间到了,RabbitMQ会将未确认消息重新加入队列中,等待重新分发给消费者。这种机制确保了消息不会丢失,并且能够被及时处理。 ### 回答2: 对于未确认消息RabbitMQ会尝试将其重新发送给其他消费者。当一个消费收到一条消息后,它会将消息标记为未确认状态,然后进行处理。如果在规定的时间内(根据配置或者默认设置)该消费者没有发送确认消息RabbitMQRabbitMQ会认为这个消息没有被正确处理,将尝试将其重新推送给其他消费者。 这个机制被称为消息应答。当一个消费者正确地处理一条消息后,它会发送应答给RabbitMQ,告知消息已被成功处理。RabbitMQ会认为该消息已被确认,并将其从队列中移除。如果消费者因故障中断,RabbitMQ会将未确认消息重新分发给其他消费者,确保消息能被正确处理。 除了消息应答,RabbitMQ还提供了其他消息确认模式,如手动确认批量确认消费者可以选择等待某个具体的条件满足后再发送确认消息,或者一次性确认多条消息,这些都可以通过配置实现。 总结起来,对于未确认消息,如果有其他消费者订阅了当前队列,RabbitMQ会尝试将未确认消息重新推送给其他消费者。这个机制保证了消息的可靠传递处理,避免了消息的丢失。 ### 回答3: 对于未确认消息,如果有其他消费者订阅了当前QUEUE,RabbitMQ 会将未确认消息推送给其他消费者。 在 RabbitMQ 中,当一个消费者从队列中获取到消息后,会发送一个确认RabbitMQ,告知已经成功处理了该消息。如果消费者在消息处理期间发生了异常,或者其它原因导致消费者无法发送确认RabbitMQRabbitMQ 会认为该消息处理失败,并将该消息重新放回队列。 当有其他消费者订阅了当前队列时,RabbitMQ 会自动将该未确认消息推送给其他消费者,供其进行消费处理。这样可以保证消息不会因为某个消费者的故障或卡顿而被丢失,提高了消息的可靠性可用性。 这种消息的重新投递分发机制,称为消息的自动负载均衡。通过自动负载均衡,RabbitMQ 能够根据消费者的处理能力负载情况,将消息均匀地分配给多个消费者,避免某个消费者被过载,并提高整体的消息处理效率。 总之,对于未确认消息RabbitMQ 会将其推送给其他消费者,从而保证消息的可靠传递消费
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值