我使用 pika for python 与 RabbitMQ 进行通信。我有 6 个线程，它们使用和确认来自同一个队列的消息。我为每个线程使用不同的连接（和通道）。所以我有几个非常接近的问题：
如果与 rabbit 的连接将在 1 个线程中关闭，并且我将重新连接，则交付标签值将重置，重新连接后将从 0 开始？
重新连接后，我将以相同的顺序为每个线程接收相同的未确认消息，或者它将开始在所有线程之间再次分发它们，或者它将从重新连接点开始？
这在我的应用程序中很重要，因为在消息接收和确认之间存在延迟，我希望避免在接下来的流程步骤中重复。
【问题讨论】：
交付标签是特定于渠道和服务器分配的。有关delivery-tag 的详细信息，请参阅AMQP spec, section 1.1.
AMQPdefined Domains 或RabbitMQ's documentation 。 delivery-tag 的 RabbitMQ 初始值为 1，
0 保留给客户端使用，意思是“到目前为止收到的所有消息”。
如果单个队列中有多个消费者，则无法保证消费者会按照排队的顺序获取消息。详见 RabbitMQ 的Broker Semantics, "Message ordering guarantees" paragraph：
AMQP 0-9-1 核心规范的第 4.7 节解释了保证排序的条件：在一个通道中发布的消息，经过一个交换和一个队列，并且一个传出通道将按照它们接收到的顺序相同被发送。自 2.7.0 版以来，RabbitMQ 提供了更强大的保证。
消息可以使用具有重新排队参数（basic.recover、basic.reject 和 basic.nack）的 AMQP 方法返回到队列，或者由于通道关闭而持有未确认的消息。对于 2.7.0 之前的 RabbitMQ 版本，任何这些情况都会导致消息在队列后面重新排队。从 RabbitMQ 2.7.0 版开始，消息始终按发布顺序保存在队列中，即使存在重新排队或通道关闭。
在 2.7.0 及更高版本中，如果队列有多个订阅者，个人消费者仍然可以观察到乱序的消息。这是由于可能重新排队消息的其他订阅者的行为造成的。从队列的角度来看，消息始终按发布顺序保存。
另外，请参阅this answer for "RabbitMQ - Message order of delivery" question。
【讨论】：