我正在同时使用Celery和Redis作为message broker和result backend。我不清楚Redis中的任务到期或KEY到期。
请清楚一点，当Celery客户端启动任务时，它将为每个任务生成一个唯一的task_id "celery-task-meta-64h4378-875ug43-6523g" this is what it stores in Redis as a KEY (Just example)并将其放入消息队列中，然后Celery工作人员将检查消息队列并基于该任务执行任务到位的工人数量。如果工作人员完成任务并将其标记为“成功/失败”，则不会将其更改为“待处理”或其他任何状态。
Celery docs说，过期时间与“发布”任务后的时间相对应，但是我找不到“发布”实际含义的任何信息。
我知道celery将任务存储为Redis密钥，并且默认到期时间为1 day (86400 seconds)。在我的情况下，一旦任务创建并存储为Redis作为KEY之后，工作人员就需要花费更多时间来执行任务并更新该任务的结果，无论它是否成功。
问题＃1：：关于Redis密钥的过期时间。是在任务执行后或创建密钥的那一天，芹菜正在创建的默认1天默认时间结果由工作人员(I mean key created in Redis -> worker started that task -> worker finished and updated the task (Key in redis))更新为密钥。.
我唯一要担心的是celery创建了新任务之后，工作人员便开始执行该任务，并花费了一天以上的时间来完成该任务（最糟糕的情况是。如果我们创建的任务越来越多）以及平均而言，如果KEY在Redis中过期... 然后在这些情况下该怎么办..？
快速解决方案是将Redis Key的过期时间增加到一天以上：）
问题2：在上述情况下，使用RabbitMq代替Redis是一个不错的选择吗？在这种情况下，我们可以将结果存储在持久数据库中，而不必担心过期时间以及Redis内存缓存填满情况。
如果我不愿意理解上述几点，请纠正我。任何对此的反馈/帮助将不胜感激：）
答案 0 :(得分：1)
问题1：您在链接中引用的过期时间是从调用apply_async或delay的时间开始。
问题2：任一个都是不错的选择。 Redis的可靠性稍差一些，但很多比rabbitmq更易于配置。也就是说，使用rabbitmq作为您的代理是迄今为止大多数开发人员最流行的选择。 YMMV。