我的大多数 Celery 任务的 ETA 都比 Amazon SQS 定义的最大可见性超时时间长。
芹菜documentation 说：
这会导致 ETA/倒计时/重试任务出现问题 执行超过可见性超时；事实上，如果发生这种情况 将再次执行，并在循环中再次执行。
因此您必须增加可见性超时以匹配 您计划使用的最长 ETA。
同时它还说：
在撰写本文时，AWS 支持的最大可见性超时为 12 小时（43200 秒）：
如果我使用 SQS，我应该怎么做才能避免在工作人员中多次执行任务？
【问题讨论】：
acks_late=False。你试过吗？您不必全局禁用 acks_late（配置设置），只需将其放在任务注释中即可。
一般来说，任务的 ETA 很长并不是一个好主意。
首先，存在“visibility_timeout”问题。而且你可能不想要一个非常大的可见性超时，因为如果工作人员在任务即将运行前 1 分钟崩溃，那么队列仍将等待可见性超时完成，然后再将任务发送给另一个工作人员，我猜你不想要这还有 1 个月。
来自 celery 文档：
请注意，Celery 将在工作人员关闭时重新传递消息，因此有 长时间的可见性超时只会延迟“丢失”的重新交付 断电或强制终止时的任务 工人。
而且，SQS 只允许列表中的许多任务被确认。
SQS 将这些任务称为“Inflight Messages”。来自http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html：
收到来自 消费者排队，但尚未从队列中删除。
对于标准队列，最多可以有 120,000 个机上 每个队列的消息。如果您达到此限制，Amazon SQS 将返回 超限错误消息。为避免达到极限，您应该 处理完消息后从队列中删除消息。你也可以 增加用于处理消息的队列数量。
对于 FIFO 队列，最多可以有 20,000 条正在进行的消息 每个队列。如果您达到此限制，Amazon SQS 不会返回错误 消息。
我看到了两种可能的解决方案，您可以改用 RabbitMQ，它不依赖于可见性超时（如果您不想自己管理，可以使用“RabbitMQ 即服务”服务），或者将代码更改为具有非常小的 ETA （最佳实践）
这是我的 2 美分，也许@asksol 可以提供一些额外的见解。
【讨论】：
Celery 以异步任务调度程序而闻名。与任务的数量无关。如果将任务发送到队列，celery 将执行任务，直到代码出现错误。在将任务发送到队列之前，您必须检查或限制重复任务。
【讨论】：
在 SQS 中，您可以更改消息的可见性时间。它记录在here。所以你要做的是，当你处理消息时，你可以定期更新可见性超时，完成后你可以删除消息。
要定期延长可见性超时，如果您正在使用某个循环，则可以在每次迭代结束时或每 x 次迭代时继续延长超时，具体取决于完成一次迭代的时间。这是执行我的意思的示例代码。
process_message(){
for(i=0;i++;..){
.
.
.
if(i%5 == 0){
extendVisibilityTimeOut(..)
}
}
}
【讨论】：