使用 Redis 作为 Celery 结果后端和消息代理 - 任务过期（对于存储在 redis 中的密钥）答案

【问题标题】：Using Redis as Celery result backend and Message broker - Task Expiration (For key stored in redis)使用 Redis 作为 Celery 结果后端和消息代理 - 任务过期（对于存储在 redis 中的密钥）
【发布时间】：2019-05-15 01:21:59
【问题描述】：

我使用 Celery、Redis 作为 message broker 和 result backend。我不清楚 Redis 中的任务过期或 KEY 过期。

需要明确的是，当 Celery 客户端启动任务时，它会生成一个唯一的 task_id "celery-task-meta-64h4378-875ug43-6523g" 这是它存储在 Redis 中作为每个任务的 KEY（只是示例）并将其放入消息队列中，Celery 工作人员将然后检查消息队列并根据工作人员的数量执行任务。如果工作人员完成了任务并将任务标记为 SUCCESS/FAILURE，它不会将其更改为 PENDING 或任何其他状态。

Celery docs 说到期时间对应于“发布”任务后的时间，但我找不到任何关于“发布”实际含义的信息。

我知道 celery 将任务存储为 Redis Key 并且默认过期时间为1 day (86400 seconds)。在我的情况下，一旦任务被创建并作为 KEY 存储在 Redis 中，工作人员需要更多时间来执行任务并更新该任务的结果，无论它可能是成功/失败。

问题#1：关于 Redis 密钥的过期时间.. celery 创建的 1 天默认时间是否从创建密钥的时间开始计算或在任务之后结果由工作人员更新为密钥（我的意思是在Redis中创建的密钥->工作人员启动了该任务->工作人员完成并更新了任务（Redis中的密钥）..？

我唯一担心的是在 celery 创建了新任务之后，worker 开始执行该任务并且需要超过一天才能完成该任务（最坏的情况......如果我们创建的任务越来越多）同时，如果 KEY 在 Redis 中过期......那么在这些情况下该怎么办......？

快速的解决方案是将redis Key的过期时间增加到一天以上:)

问题 #2： 在上述场景中使用 RabbitMq 而不是 Redis 是一个不错的选择吗..？在这种情况下，我们可以将结果存储在持久化数据库中，我们不必担心过期时间以及 Redis In-Memory 缓存填充情况。

如果我对上述几点中的某些内容不理解，请纠正我。对此的任何反馈/帮助将不胜感激:)

【问题讨论】：

标签： python-3.x redis rabbitmq celery

【解决方案1】：

问题 #1：您在链接中引用的过期时间是从调用 apply_async 或 delay 开始的时间。

问题 #2：任何一个都是不错的选择。 Redis 的可靠性稍差，但比 rabbitmq 更容易配置。也就是说，使用 rabbitmq 作为你的代理是迄今为止大多数开发人员最流行的选择。 YMMV。

【讨论】：