我目前正在致力于将现有的基于 Django 的单服务器 Web 项目移植到 Amazon Elastic Beanstalk。到目前为止，我已经成功地将项目设置为使用 RDS、Elastic Search、简单电子邮件服务和 S3，没有遇到太多麻烦。我正在使用 Code Deploy 为 Django 项目构建 Docker 容器并部署到 Elastic Beanstalk 环境。所有这些都工作得很好，但我在尝试让 Elastic Beanstalk 工作线程环境与此设置配合良好时遇到了问题。
我正在将相同的 Docker 容器部署到我的工作环境，但使用不同的起点来运行celery -A项目worker -l INFO而不是gunicorn config.wsgi --bind 0.0.0.0:5000 --chdir=/app --workers 3。这似乎有效；工作线程消耗消息并处理它们，但它经常看起来一次停止工作几分钟，即使队列中有积压的消息等待。
在测试过程中，我尝试运行发票生成例程，该例程通过在链中使用 Celery group 为每个帐户的发票排队消息，因此它将处理发票，然后通过电子邮件向我发送“已完成”通知。一开始队列中总共有大约 250 条消息。跟踪 Docker 容器的 celery 日志，我可以看到 8 到 12 条消息的组被拾取，然后在一两秒内进行处理，但随后工作线程一次空闲几分钟。通常大约 4 分钟。
在我能想到的任何地方都没有看到任何错误。
我还尝试过扩展工作线程环境，以便它运行多个工作线程节点，但这只是将问题分散到多个节点。即，不是由一名工作人员拾取 8-12 条消息，而是两名工作人员拾取 4-6 条消息，处理它们，然后闲置。
此时，我不知道我应该再关注什么，并且我正在考虑完全取消工作环境。也许在与 Web 服务器相同的环境中运行 Celery 工作进程更有意义？我不想这样做，因为我认为独立设置 Web 服务器和工作人员的扩展规则会更容易，但开始看起来我别无选择。
此设置中是否缺少某些内容，或者 Celery 工作环境以这种方式运行的某些原因？
最佳答案
鉴于更改 celery 工作线程或节点的数量不会改变延迟，这让我相信问题出在给定 celery 工作线程如何尝试从 SQS 队列中提取任务的方式上。
超时 4 分钟后，看起来非常接近 default retry delay present in Celery's Task.default_retry_delay，即3分钟。它还可能与 Task.rate_limit、the config parameter 有关。这将限制 celery 工作人员在给定时间单位内接受的任务总数。
作为第一步，我将进入您的 celery 配置文件并手动更改这两个值 - 使它们更高，并查看它如何影响超时或更改应用程序吞吐量。
关于django - 在 Amazon Elastic Beanstalk 上使用 SQS 的 Celery 在消息等待时经常长时间暂停，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/55264657/