RabbitMQ学习(十六)：消息确认之消费者确认模式 I

小灰灰 2021-11-19 11:52 483阅读 0赞

# 说明 #

通过上篇博文[《RabbitMQ学习(十五)：消极确认》][RabbitMQ]我们初步了解了消费者对消息确认的相关内容，通过消极确认，消费者可以拒绝一个消息。本篇博文，我将继续翻译学习官方文档中关于消息确认的相关内容。由于原文档太长，本篇博文只翻译消费者确认的部分内容。通过本篇博文，我们将了解到消息确认机制的意义，消息确认的不同模式，消息确认对吞吐量的影响等内容。

# 概述 #

消息者确认机制和发送者确认机制对数据安全十分重要，本文将围绕以下几个要点展开：

*  为什么要有确认机制？
 *  手动确认和自动确认的区别
 *  进行消息确认的API的不同用法，实现不同的目的 – 批量确认 和 重新入队
 *  连接丢失或通道关闭时，消息安全性的保证 (自动重新入队)
 *  影响吞吐量的通道最大累积未确认消息数量的设置

## 消息确认的必要性 ##

使用消息中间件（如 RabbitMQ）的系统被定义为分布式系统。因为中间件使用的协议方法在发送消息后不能保证消息已经被接收或者已经被成功处理，所以发送者和消费者需要对消息发送和处理进行确认的机制。RabbitMQ支持的一些协议中提供了类似的功能。

AMQP 0-9-1协议支持消息者对服务器进行消息传输确认，同时该协议有一**个被称为发送者确认的扩展**，服务器用来对发送者进行确认。这两种方式都基于相同的思想，受到了TCP的启发影响。

发送者到服务器，服务器到消息者，这中间的消息传输的可靠性是必须的。换句话说，它们**对数据的安全性是必须的**，数据安全对应用程序和RabbitMQ一样重要。

--------------------

## 消息者传输确认 ##

当服务器发送一个消息到消费者，它需要知道什么时候消息可以被认为已经成功发送。这个时机有系统决定，它主要是一个应用程序的选择。在AMQP 0-9-1协议中，当一个消费者被注册后，使用basic.consumer方法或者消息者根据需要使用basic.get方法来消费消息。

### 传输标签（Delivery Tags） ###

在我们学习其他内容之前，我们必须清楚服务器如何确认每次的传输(确认消息表明属于哪个传输)。当消费者被注册后，**服务器将使用basic.deliver方法将消息推送给消费者。这个方法携带了一个传输标签，该标签具有唯一性，表明了在该通道的哪次传输。因此，传输标签只能作用于每个通道**。

**传输标签是一个单调递增的正整数**，严格意义上由客户端库提供。客户端库方法在确认时，将一个传输标签作为参数进行传递。

**传输标签作用于每个通道，所以传输的确认通道必须与接收的通道一致**。当在不同的通道上进行确认时，将引起"unknown delivery tag"协议异常，并且导致通道关闭。

### 消费者确认模式和数据安全 ###

当服务器发送消息到消费者时，它必须决定消息是否可以被以为已经被消息处理（或者至少已经被接收到）。由于多种因素（客户端连接，消费者程序等）会失败崩溃，所以这个决定关乎着数据安全问题。消息传输协议经常提供一个确认机制，它允许消费者进行传输确认。这个机制是否被使用在消费者订阅时决定。

依赖于确认机制的使用，RabbitMQ可以认为一个消息在被发送后或者是接收到一个明确的客户端确认消息后，该消息已经被成功发送。手动发送确认消息时，可以使用以下协议方法发送积极确认或消极确认消息：

*  basic.ack 被用来发送积极确认
 *  basic.nack 被用来发送消极确认 （这个发送时RabbitMQ对AMQP 0-9-1协议的一个扩展）
 *  basic.reject 被用来发送消极确认，但与basic.nack方法有个限制

关于消极确认的两个方法，详见 [RabbitMQ学习(十五)：消极确认][RabbitMQ]

积极确认消息告诉服务器消息已被发送可以丢弃（删除）。使用basic.reject方法发送的消极确认消息具有同样的效果，但是它们之间**最主要的区别是：积极确认消息假定消息已经被成功处理，然而消极确认消息表明消息没有被处理单仍应该被删除**。

**在自动消息确认模式中，一个消息在被发送后就立即被认为已经成功传递。该模式可以实现更高的吞吐量，但牺牲了传输和消费者处应该理的安全性。这个模式经常被认为是“发后即忘”**。不像手动确认模式，如果消费者的TCP连接或者通道在成功传输前被关闭，服务器发送的消息将会丢失。因此，自动消息确认机制应该被任务时不安全的，并且不适用于所有的场景。

另外，当使用自动消息确认模式时，消息者可能会过载（内存溢出）。**手动确认模式设置了通道的prefetch值来限制在该通道中未被确认（正在被处理）的消息的数量。然而，在自动确认模式中，没有类似的限制。所以，消费者可能会因为消息的传输速率过快，造成消息在内存中积压使得内存耗尽，导致内存溢出或者被系统终止程序**。在一些客户端中，使用了TCP来缓解压力（停止从socket缓冲区读取消息，直到积压的消息数量降低到临界值以下）。因此，自动消息确认模式仅推荐用于处理消息速度快并且稳定的消费者。

[RabbitMQ]: https://blog.csdn.net/sinat_36553913/article/details/94991088