如何在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屋！