1

我在 Django 中使用芹菜。我必须为用户提供一个选项来检查失败的任务，必要时对失败的任务数据进行修改并再次提交。我见过这个线程 -Celery Storing unrecoverable task failures for later resubmission。所以我知道 celery 不存储任务的原始 args 和 kwargs，我们需要注意这一点。我可以这样做。但是，如果我有一个提交链“SubTask1 | SubTask2 | SubTask3”的主任务“MainTask1”，并且如果 SubTask2 失败，那么我看到在 SubTask2 成功之前不会执行 SubTask3。但是如果 SubTask2 在最大重试次数后失败，则 SubTask3 永远不会提交。

我的问题是——

  1. 当 SubTask2 失败时，我可以坚持 args 和 kwargs。但是如何获取链中剩余任务的信息呢？

  2. celery_taskmeta 表的“result”和“meta”列中究竟存储了什么？

  3. 何时填充表 celery_tasksetmeta？

谢谢，

4

1 回答 1

2

  1. 您可以为此使用结果（例如AsyncResult(id).ready，请参阅http://docs.celeryproject.org/en/latest/reference/celery.result.html），但这不能通过 amqp 后端可靠地完成，因为只有一个进程可以检索结果。

  2. 后端 APi 中使用的名称不一致且已过时。这是因为术语随着时间的推移发生了相当大的变化，并且自 celery 0.1 以来后端几乎向后兼容。起初，任务仅在成功或失败时才存储数据。这使用了字段status和result. 最终，我意识到很容易将其扩展到支持随任务进行而更新的任意状态，而这只是在已经存在的基础上实现的。

    result 字段包含任务成功时任务的返回值，或任务失败时引发的异常。自定义状态可以在此字段中存储任意数据，因此在较新的术语中，任务状态可以附加信息，这就是存储信息的位置。

    元字段是后来添加的，因为我厌倦了一直添加新字段（并强迫用户迁移模式），它用于不需要索引的新字段，目前它只保存children属性，这是一个任务启动的子任务 ID 列表

    希望有一天能把它清理干净。大多数其他“成长的烦恼”在很久以前就已经被重构了，但结果后端仍然存在。

  3. GroupResult.save（以前的TaskSetResult）用于存储组结果以供以后检索，因此您只需保留组ID即可获取组中的任务ID列表。此功能目前仅由 Redis 结果后端用于实现和弦，这将在未来改变，因为它对于具有许多任务的组不是很有效。save 选项是由用户请求实现的，但我认为包含它是我的一个错误选择，用户最好这样做（比如存储您提到的任务参数/kwargs）。

于 2012-12-06T16:36:33.420 回答