rabbitmq 学习 之Consumer Cancel Notification（33）

https://www.rabbitmq.com/consumer-cancel.html

 

Overview

When a channel is consuming from a queue, there are various reasons which could cause the consumption to stop. One of these is obviously if the client issues a basic.cancel on the same channel, which will cause the consumer to be cancelled and the server replies with a basic.cancel-ok. Other events, such as the queue being deleted, or in a clustered scenario, the node on which the queue is located failing, will cause the consumption to be cancelled, but the client channel will not be informed, which is frequently unhelpful.

当渠道正在从队列消费的时候，有许多原因可以导致消费终止，例如客户端调用了basic.cancel 会导致服务器端响应basic.cancel-ok,其他事件例如队列被删除，或者在集群场景 节点挂了 ，客户端渠道不会受到通知

To solve this, we have introduced an extension in which the broker will send to the client a basic.cancel in the case of such unexpected consumer cancellations. This is not sent in the case of the broker receiving a basic.cancel from the client. AMQP 0-9-1 clients don't by default expect to receive basic.cancel methods from the broker asynchronously, and so in order to enable this behaviour, the client must present a capabilities table in its client-properties in which there is a key consumer_cancel_notify and a boolean value true. See the section on capabilities for details.

为了解决这个问题，我们引入了一个扩展机制 ：在这种意外的消费者取消的情况下，服务器会发送给客户端一个取消通知。不包括消费者主动取消的情况。默认情况下，AMQP 0-9-1客户端不希望异步接收 来自代理的basic.cancel方法，因此为了启用此行为，客户端必须在其客户端属性中提供一个功能表，其中存在key consumer_cancel_notify和布尔值 true。有关详细信息，请参阅功能部分。

Our supported clients present this capability by default to the broker and thus will be sent the asynchronous basic.cancel method by the broker, which they present to the consumer callback. For example, in our Java client, the Consumer interface has a handleCancel callback, which can be overridden by sub-classing the DefaultConsumer class:

默认情况下，我们支持的客户端将此功能提供给代理，因此将由代理发送异步 basic.cancel方法，并将它们呈现给消费者回调。例如，在我们的Java客户端中，Consumer接口有一个 handleCancel回调，可以通过对DefaultConsumer类进行子类化来覆盖它：

channel.queueDeclare(queue, false, true, false, null);
Consumer consumer = new DefaultConsumer(channel) {
    @Override
    public void handleCancel(String consumerTag) throws IOException {
        // consumer has been cancelled unexpectedly
    }
};
channel.basicConsume(queue, consumer);

It is not an error for the client to issue a basic.cancel for a consumer which has been unexpectedly cancelled (e.g. due to queue deletion). By definition, there is a race possible between a client issuing a basic.cancel, and the broker sending out the asynchronous notification. In such cases, the broker does not error when it receives the basic.cancel and replies with a basic.cancel-ok as normal.

客户端为意外取消的消费者（例如，由于队列删除）发出basic.cancel并不是错误 。根据定义，发出basic.cancel的客户端和发出异步通知的代理之间可能存在竞争。在这种情况下，代理在收到basic.cancel时不会出错， 并且正常回复 basic.cancel-ok。

 

Consumer Cancellation and Mirrored Queues

Clients supporting consumer cancel notification will always be informed when a queue is deleted or becomes unavailable. Consumers may request that they should be cancelled when a mirrored queue fails over (see the page on mirrored queues for why and how this can be done).

当队列被删除或变得不可用时，将始终通知支持消费者取消通知的客户端。当镜像队列进行故障转移时，消费者可能会要求取消它们（请参阅镜像队列中的页面， 了解为何以及如何进行此操作）

Client and Server Capabilities

The AMQP 0-9-1 specification defines a way for clients and servers to express their capabilities using the capabilities field as part of the connection.open method. This field was deprecated in the AMQP 0-9-1 specification and is not inspected by the RabbitMQ broker. As specified in AMQP 0-8, it also suffered from being a shortstr: a string of no more than 256 characters.

AMQP 0-9-1规范为客户端和服务器定义了一种使用capabilities字段作为connection.open方法的一部分来表达其功能的 方法。该字段在AMQP 0-9-1规范中已弃用，RabbitMQ代理不会对其进行检查。正如AMQP 0-8中所规定的那样，它也是一个shorttr：一个不超过256个字符的字符串。

There is good reason for both the client and the server being able to present extensions and capabilities that they support, thus we have introduced an alternative form of capabilities. In the server-properties field of connection.start, and in the client-properties field of connection.start-ok, the field value (a peer-properties table) can optionally contain a key named capabilities for which the value is another table, in which the keys name the capabilities supported. The values for these capability keys are typically booleans, indicating whether or not the capability is supported, but may vary based on the nature of the capability.

客户端和服务器都能够提供它们支持的扩展和功能是有充分理由的，因此我们引入了另一种形式的功能。在connection.start的server-properties字段中 ，以及connection.start-ok的 client-properties字段中 ，字段值（ 对等属性表）可以选择包含名为capabilities的键，其值是另一个表，其中键命名支持的功能。这些功能键的值通常是布尔值，表示是否支持该功能，但可能会根据功能的性质而有所不同。

For example, the server-properties presented by the RabbitMQ broker to a client may look like:

例如，RabbitMQ代理向客户端提供的服务器属性可能如下所示：
{ "product"      = (longstr) "RabbitMQ",
  "platform"     = (longstr) "Erlang/OTP",
  "information"  = (longstr) "Licensed under the MPL.  See http://www.rabbitmq.com/",
  "copyright"    = (longstr) "Copyright (c) 2007-2019 Pivotal Software, Inc.",
  "capabilities" = (table)   { "exchange_exchange_bindings" = (bool) true,
                               "consumer_cancel_notify"     = (bool) true,
                               "basic.nack"                 = (bool) true,
                               "publisher_confirms"         = (bool) true },
  "version"      = (longstr) "3.7.12" }

Note that it is optional for clients to present this capabilities table as part of the client-properties table: failure to present such a table does not preclude the client from being able to use extensions such as exchange to exchange bindings. However, in some cases such as consumer cancellation notification, the client must present the associated capability otherwise the broker will have no way of knowing that the client is capable of receiving the additional notifications.
请注意，客户端将此功能表作为客户端属性表的一部分 提供是可选的 ：未能提供此类表并不妨碍客户端能够使用诸如交换之类的扩展来交换绑定。然而，在诸如消费者取消通知的某些情况下，客户端必须呈现相关联的能力，否则服务器将无法知道客户端能够接收附加通知。