1

私はdjangoでセロリを使用しています。失敗したタスクを調べ、必要に応じて失敗したタスクのデータを変更し、再度送信するオプションをユーザーに提供する必要があります。私はこのスレッドを見てきました - Celery Storeing unrecoverable task failures for later resubmission。したがって、セロリはタスクの元の引数とkwargsを保存しないことを理解しており、それを処理する必要があります。私はそれで大丈夫です。しかし、チェーン「SubTask1 | SubTask2 | SubTask3」を送信するメインタスク「MainTask1」があり、SubTask2 が失敗した場合、SubTask2 が成功するまで SubTask3 が実行されないことがわかります。ただし、SubTask2 が最大再試行後に失敗した場合、SubTask3 は送信されません。

私の質問は -

  1. SubTask2 が失敗した場合、その引数と kwargs を永続化できます。しかし、チェーン内の残りのタスクの情報を取得するにはどうすればよいでしょうか?

  2. celery_taskmeta テーブルの「result」列と「meta」列には正確に何が格納されていますか?

  3. テーブル celery_tasksetmeta はいつ入力されますか?

ありがとう、

4

1 に答える 1

2

  1. そのための結果を使用することもできますが（たとえば、 http：AsyncResult(id).ready //docs.celeryproject.org/en/latest/reference/celery.result.htmlを参照）、amqpバックエンドでは1つのプロセスしか取得できないため、これを確実に行うことはできません。結果。

  2. バックエンドAPiで使用されている名前は一貫性がなく、古くなっています。これは、用語が時間の経過とともにかなり進化し、バックエンドがcelery0.1以降かなり下位互換性があるためです。最初、タスクは成功または失敗したときにのみデータを保存しました。これはフィールドstatusとを使用しましたresult。最終的に、これをタスクの進行に応じて更新される任意の状態をサポートするように拡張するのは簡単であり、これは既存のものに単純に実装されていることに気付きました。

    結果フィールドには、タスクが成功したときのタスクの戻り値、またはタスクが失敗したときにタスクで発生した例外が含まれます。カスタム状態はこのフィールドに任意のデータを格納できるため、新しい用語では、タスク状態に情報を添付でき、ここに情報が格納されます。

    メタフィールドは、常に新しいフィールドを追加する（そしてユーザーにスキーマの移行を強制する）ことにうんざりしていたため、後で追加されました。これは、インデックスを作成する必要のない新しいフィールドに使用され、現在はchildren属性のみを保持しています。タスクによって開始されたサブタスクIDのリスト

    うまくいけば、いつかこれをきれいにすることが可能になるでしょう。他の「成長痛」のほとんどは、何年も前にすでにリファクタリングされていますが、結果のバックエンドは残っています。

  3. GroupResult.save（以前のTaskSetResult）は、後で取得するためにグループの結果を格納するために使用されるため、グループIDを保持するだけで、グループ内のタスクIDのリストを取得できます。この機能は、現時点でコードを実装するためにRedis結果バックエンドでのみ使用されます。これは、多くのタスクを持つグループにはあまり効率的ではないため、将来変更される予定です。保存オプションはユーザーの要求によって実装されましたが、それを含めることは私の側では悪い選択だったと思います。ユーザーがそれを行う方がよいと思います（あなたが言及したタスク引数/ kwargsの保存など）。

于 2012-12-06T16:36:33.420 に答える