Question

我的大多数Celery任务的ETA都比Amazon SQS定义的最大可见性超时长。

这会导致ETA /倒计时/重试任务出现问题   执行超过可见性超时;事实上，如果发生这种情况   将再次执行，并再次循环执行。

因此，您必须增加可见性超时以匹配时间   您计划使用的最长的ETA。

同时它也说：

撰写本文时，AWS支持的最大可见性超时是 12小时（43200秒）：

如果我使用SQS，我该怎么做才能避免在我的工作人员中多次执行任务？

Answer 1

通常，使用非常长的ETA进行任务并不是一个好主意。

首先，有＆＃34; visibility_timeout＆＃34;问题。你可能不希望一个非常大的可见性超时，因为如果工作人员在任务即将运行前1分钟崩溃，那么队列仍将等待visibility_timeout完成，然后将任务发送给另一个工作人员，我想你不想要这是另一个月。

来自芹菜文档：

请注意，Celery将在工作人员关闭时重新发送消息，因此具有长时间的可见性超时只会延迟“丢失”的重新传递电源故障或强行终止时的任务工人。

而且，SQS只允许在列表中执行许多任务。

SQS将这些任务称为＆＃34; Inflight Messages＆＃34;。来自http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html：

在收到消息后，该消息被视为正在进行中   由消费者排队，但尚未从队列中删除。

对于标准队列，最多可以有120,000个机上   每个队列的消息。如果达到此限制，Amazon SQS将返回此限制   OverLimit错误消息。为了避免达到极限，你应该   在重新处理后从队列中删除邮件。你也可以   增加用于处理邮件的队列数量。

对于FIFO队列，最多可以有20,000个机上信息   每个队列。如果达到此限制，Amazon SQS不会返回任何错误   消息。

我看到两种可能的解决方案，您可以使用RabbitMQ，它不依赖于可见性超时（有＃34; RabbitMQ作为服务＆＃34;服务，如果您不想管理自己的）或更改您的代码拥有非常小的ETA（最佳实践）

这些是我的2美分，也许@asksol可以提供一些额外的见解。

Answer 2

Celery以异步任务计划程序而闻名。任务的数量真的无关紧要。如果将任务发送到队列，芹菜将执行任务，直到代码中出现错误。在将任务发送到队列之前，您必须检查或限制重复的任务。

Answer 3

在SQS中，您可以在消息中更改可见性时间。已记录在here中。因此，您需要做的是，在处理消息时，您可以定期更新可见性超时，一旦完成，您就可以删除消息。

要定期延长可见性超时，如果您使用某个循环，则可以根据完成一次迭代的时间，在每次迭代的末尾或每x迭代次数中继续扩展超时。这是执行我的意思的示例代码。

process_message(){
  for(i=0;i++;..){
    .
    .
    .
    if(i%5 == 0){
     extendVisibilityTimeOut(..)
    }
  }
}

Answer 4

但是here sqs表示收到邮件时可见性超时开始由消费者使用，因此即使可见性超时为1小时，并且您使用的是12个月的eta值，可见性超时也将在消费者收到消息后开始。我在这里想念东西吗？

Celery SQS +任务复制+ SQS可见性超时

4 个答案: