RabbitMQ：清除队列
我有一些队列，例如：
online_queue = self._channel.queue_declare(
durable = True,
queue = 'online'
)
目前，我需要刷新该队列中的所有内容。 但是，此时，另一个进程可能会发布到该队列。 如果我使用channel.queue_purge(queue='online')，当queue_purge仍在工作时，已发布的消息会发生什么情况？
I have some queue, for etc:
online_queue = self._channel.queue_declare(
durable = True,
queue = 'online'
)
At the moment, I need to flush all content in this queue.
But, at this moment, another process, probably, may publish to this queue.
If I use channel.queue_purge(queue='online'), what will happened with messages, published, while queue_purge still working?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
根据您的最终目标，您也许可以通过使用临时队列来解决此问题。
为了让事情更清楚，让我们给事物一些名称。调用您当前的队列（您要清除的队列）Queue A，并假设它与 Exchange A 1-1 绑定。
如果您创建一个新队列（队列 B）并以与 Queue A 相同的方式将其绑定到 Exchange A绑定后，队列 B 现在将获取队列 A 获取的所有消息（从绑定时起）。
现在，您可以安全地清除队列 A，而不会丢失绑定队列 B 后发送的任何消息。
将队列 A 重新绑定到 Exchange A，您就可以恢复并运行。
然后，您可以根据需要处理队列 B 中的“临时”消息。
这样做的优点是具有非常明确的行为，并且不会让您陷入任何竞争条件，因为您可以完全清除队列 A 并重新创建它而不是清除。
Depending on your ultimate goal, you might be able to solve this issue by using a temporary queue.
To make things more clear, lets give things some names. Call your current queue (the one you want to purge) Queue A, and assume it is 1-1 bound to Exchange A.
If you create a new queue (Queue B) and bind it to Exchange A in the same way that Queue A is bound, Queue B will now get all of the messages (from the time of binding) that Queue A gets.
You can now safely purge Queue A without loosing any of the messages that got sent in after Queue B was bound.
Re-bind Queue A to Exchange A and you are back up and running.
You can then deal with the "interim" messages in Queue B however you might need to.
This has the advantage of having a very well defined behavior and doesn't get you into any race conditions because you can completely blow Queue A away and re-create it instead of purging.
您正在描述竞争条件。有些可能会留在队列中，有些可能会被清除。否则他们都会被清除。否则他们都不会被清除。
没有办法告诉你，因为这是一个依赖于时间的情况。您应该重新检查是否需要清除仍处于活动状态的队列，或者构建一个更强大的消费者，该消费者可以接受它所连接的队列中可能存在消息的事实（这基本上是消费者必须忍受的） ， 反正）。
You're describing a race condition. Some might remain in the queue and some others might get purged. Or all of them will get purged. Or none of them will get purged.
There's just no way to tell, because it's a time-dependent situation. You should re-examine your need to purge a queue which is still active, or build a more robust consumer that can live with the fact that there might be messages in the queue it is connecting to (which is basically what consumers have to live with, anyway).