芹菜SQS +任務重複+ SQS可見性超時

Question

我的大部分Celery任務的ETA時間長於Amazon SQS定義的最大可見性超時。

芹菜documentation說：

這會導致ETA問題/倒計時/重試在時間 執行超過了可見性超時工作;事實上，如果發生這種情況， 將再次執行，並再次執行循環。

因此，您必須增加可見性超時以匹配您計劃使用的最長ETA的時間 。

同時它也說：寫這篇文章的通過AWS支持

最大的可見性超時是 12小時（每次43200秒）：

我應該怎麼如果我使用SQS，是否要避免多次執行我的工作中的任務？

Answer 1

一般來說，使用非常長的ETA來完成任務並不是一個好主意。

首先，存在「visibility_timeout」問題。你可能不想要一個非常大的可見性超時，因爲如果工作人員在任務即將運行之前崩潰1分鐘，那麼在將任務發送給另一個工作人員之前，隊列仍然會等待visibility_timeout完成，我想你不想要這是另一個1個月。

芹菜文檔：

注意，芹菜會重新傳遞在工人關閉消息，所以有 長的可見性超時只會拖延的「丟失」 任務交還在斷電的情況下，或強行終止了工作人員 。

此外，SQS只允許在列表中列出很多任務。

SQS將這些任務稱爲「機上消息」。從http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html：

的消息被認爲是它是從 隊列收到消費者後，但尚未從隊列中刪除是在飛行。

對於標準隊列，每個隊列最多可以有120,000個機上郵件 。如果達到此限制，Amazon SQS將返回 OverLimit錯誤消息。爲避免達到限制，您應該在隊列處理後從隊列中刪除消息。您還可以通過 增加用於處理消息的隊列數。

對於FIFO隊列，每個隊列最多可以有20,000個機上消息 。如果達到此限制，Amazon SQS不會返回錯誤 消息。

我看到兩種可能的解決方案，您可以使用RabbitMQ的來代替，該犯規依靠可視性超時（有「的RabbitMQ即服務」，如果你不想自己管理服務）或更改您的代碼有非常小的ETAs（最佳做法）

這些是我的2美分，也許@asksol可以提供一些額外的見解。