Django-Q¶

Celeryより軽量かつDjango用に作られたタスクキュー。

https://django-q.readthedocs.io/en/latest/index.html

DjangoからBroker(RedisとかAmazon SQS)にタスクを放り込んで、django-qのworkerが処理する。
リクエストを受け付けた時、HTTPの応答はすぐに返すけど、裏で非同期にタスクを実行したい場合に使う。

Memo¶

• Asynchronous tasks in Django with Django Q: https://www.valentinog.com/blog/django-q/
• django-q+supervisorで非同期処理: https://yamakiy.hatenadiary.jp/entry/2018/12/01/125418
• リトライ周り
  • BrokerにRedisを選ぶと、receiptsに対応していないのでリトライ出来ない
  • 一番依存関係が少なくて済むのはDjango ORM（Djangoと同じDBを使う）
  • Timeoutは タスクのタイムアウト
  • Retryは タスクをworkerのキューに積み直すまでの時間
    • なので retry > timeout にしないと、タスクがタイムアウトする前に別のworkerにタスクが積まれて、同じ処理が2個同時に走ることになる
• taskのコード更新
  • 残念ながら、taskとなるpythonコードを更新してもqclusterを再起動しないと古いtaskが再利用される: https://github.com/Koed00/django-q/issues/427
• hookはasync_taskが失敗しても実行される
  • 例えばtask側で raise RuntimeError("error") すると task.result には例外メッセージの全文がstringで入っている
• Chainsで複数のタスクを連続で実行することができる
  • でも別に前のタスクの結果を次のタスクに渡せるわけではない
  • タスク自体はそれぞれ別個のエントリとして登録される
    • そのため、失敗したら失敗したタスクから再実行される
    • Retry, timeoutは個々のタスク単位で機能する（task_group全体でtimeoutを設定することは出来ない）
  • Chainを途中でやめることはできない
    • 例えば、1個目のタスクが失敗したら2個目のタスクを実行しないようにすることはできない