我使用 pika for python 与 RabbitMQ 通信。我有 6 个线程，它们使用并确认来自同一队列的消息。我为每个线程使用不同的连接(和 channel )。所以我有几个非常接近的问题:
如果与 rabbit 的连接将在线程 1 中关闭，并且我将重新连接，交付标签值将重置，重新连接后它将从 0 开始？
重新连接后，我会以相同的顺序为每个线程接收相同的未确认消息，或者它会开始在所有线程之间再次分发它们，或者它会从重新连接点开始？
这在我的应用程序中很重要，因为消息接收和确认之间存在延迟，我想避免在接下来的流程步骤中出现重复。
请您参考如下方法:
交付标签是特定于 channel 和服务器分配的。详见 AMQP spec, section 1.1. AMQPdefined Domains或 RabbitMQ's documentation 对于
delivery-tag。delivery-tag的 RabbitMQ 初始值为1,Zero is reserved for client use, meaning "all messages so far received".
如果单个队列中有多个消费者，则无法保证消费者将按照他们排队的相同顺序获取消息。请参阅 RabbitMQ 的 Broker Semantics, "Message ordering guarantees" paragraph详情:
Section 4.7 of the AMQP 0-9-1 core specification explains the conditions under which ordering is guaranteed: messages published in one channel, passing through one exchange and one queue and one outgoing channel will be received in the same order that they were sent. RabbitMQ offers stronger guarantees since release 2.7.0.
Messages can be returned to the queue using AMQP methods that feature a requeue parameter (basic.recover, basic.reject and basic.nack), or due to a channel closing while holding unacknowledged messages. Any of these scenarios caused messages to be requeued at the back of the queue for RabbitMQ releases earlier than 2.7.0. From RabbitMQ release 2.7.0, messages are always held in the queue in publication order, even in the presence of requeueing or channel closure.
With release 2.7.0 and later it is still possible for individual consumers to observe messages out of order if the queue has multiple subscribers. This is due to the actions of other subscribers who may requeue messages. From the perspective of the queue the messages are always held in the publication order.
另请参阅 this answer for "RabbitMQ - Message order of delivery" question .
