如何在 RabbitMQ 中撤回消息? [英] How to retract a message in RabbitMQ?

问题描述

我有类似 RabbitMQ 上的作业队列，并且在请求取消作业时，我想撤回尚未开始处理的任务(它们的消息尚未被确认)，这对应于从它们被路由到的队列中收回这些消息.

I've got something like a job queue over RabbitMQ and, upon a request to cancel a job, I'd like to retract the tasks that have not yet started processing (their messages have not been ack'd), which corresponds to retracting these messages from the queues that they've been routed to.

我没有在 AMQP 或 RabbitMQ API 中找到这个功能；也许我搜索得不够好?还是我必须使用解决方法(这并不难，但仍然如此)?

I haven't found this functionality in AMQP or in the RabbitMQ API; perhaps I haven't searched well enough? Or will I have to use a workaround (it's not hard, but still)?

推荐答案

我会通过让工作人员检查某种权威数据源来确定工作是否应该继续来解决这种情况.例如，工作人员会在数据库中检查作业的状态，以查看作业是否已被取消.

I would solve this scenario by having the worker check some sort of authoritative data source to determine if the the job should proceed or not. For example, the worker would check the job's status in a database to see if the job was canceled already.

对于处理作业的速度可能快于更新和读取权威存储的速度的情况，以速度换取其他特性的保证较少的数据存储可能会很有用.

For scenarios where the speed of processing jobs may be faster than the speed with which the authoritative store can be updated and read, a less guaranteed data store that trades speed for other characteristics may be useful.

这方面的一个例子是使用 Redis 作为取消处理消息的存储，而不是像 MySQL 这样的关系数据库.Redis 非常快，但对其所持有的数据提供的保证较少，而 MySQL 则慢得多，但对其所持有的数据提供更多的保证.

An example of this would be to use Redis as the store for canceling processing of a message instead of a relational DB like MySQL. Redis is very fast, but makes fewer guarantees regarding the data it holds, whereas MySQL is much slower, but offers more guarantees about the data it holds.

最后，与另一个来源检查是否处理消息的概念是相同的，但您实现的方式取决于您的特定场景.

In the end, the concept of checking with another source for whether or not to process a message is the same, but the way you implement that depends on your particular scenario.

这篇关于如何在 RabbitMQ 中撤回消息?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！