これは、まったく同じ質問に答えようとしているときに私が見つけたものです。それはおそらく包括的ではなく、いくつかの点で不正確でさえあるかもしれません。
要するに、RQは全体的にシンプルになるように設計されています。セロリは、より堅牢になるように設計されています。どちらも優れています。
- ドキュメンテーション。RQのドキュメントは複雑ではなく包括的であり、プロジェクトの全体的な単純さを反映しています。迷ったり混乱したりすることはありません。Celeryのドキュメントも包括的ですが、内部化するにはオプションが多すぎるため、最初に設定するときに、かなり多くのことを再検討することを期待してください。
モニタリング。Celery's FlowerとRQダッシュボードはどちらもセットアップが非常に簡単で、必要なすべての情報の少なくとも90%を提供します。
ブローカーのサポート。セロリが明らかに勝者であり、RQはRedisのみをサポートしています。これは、「ブローカーとは何か」に関するドキュメントが少なくなることを意味しますが、Redisが機能しなくなった場合、将来ブローカーを切り替えることができないことも意味します。たとえば、InstagramはRedisとRabbitMQの両方をCeleryで検討しました。ブローカーが異なれば保証も異なるため、これは重要です。たとえば、Redisは(執筆時点では)メッセージの配信を100%保証することはできません。
優先キュー。RQの優先キューモデルはシンプルで効果的です。ワーカーはキューから順番に読み取ります。セロリでは、異なるキューから消費するために複数のワーカーを起動する必要があります。どちらのアプローチも機能します
OSサポート。fork
RQはUnixシステムなどをサポートするシステムでのみ実行されるため、Celeryがここでの明確な勝者です。
言語サポート。RQはPythonのみをサポートしますが、Celeryではタスクをある言語から別の言語に送信できます
API。Celeryは非常に柔軟性があります(複数の結果バックエンド、優れた構成形式、ワークフローキャンバスのサポート)が、当然、この機能は混乱を招く可能性があります。対照的に、RQAPIは単純です。
サブタスクのサポート。Celeryはサブタスクをサポートします(たとえば、既存のタスク内から新しいタスクを作成する)。RQがするかどうかわかりません
コミュニティと安定性。セロリはおそらくもっと確立されていますが、どちらも活発なプロジェクトです。執筆時点で、CeleryのGithubには約3500の星があり、RQの星は約2000であり、どちらのプロジェクトも活発な開発を示しています
私の意見では、Celeryはその評判があなたを信じさせるほど複雑ではありませんが、RTFMを行う必要があります。
では、なぜ誰かが(おそらくよりフル機能の)セロリをRQと交換することをいとわないのでしょうか?私の考えでは、それはすべて単純さに帰着します。RQは、Redis + Unixに制限することで、よりシンプルなドキュメント、よりシンプルなコードベース、およびよりシンプルなAPIを提供します。これは、タスクキューシステムの詳細を作業メモリに保持する代わりに、あなた(およびプロジェクトへの潜在的な貢献者)が関心のあるコードに集中できることを意味します。一度に頭に入れることができる詳細の数には制限があり、タスクキューの詳細をそこに保持する必要をなくすことで、RQは気になるコードに戻ることができます。その単純さは、言語間タスクキュー、幅広いOSサポート、100%信頼できるメッセージ保証、メッセージブローカーを簡単に切り替える機能などの機能を犠牲にしてもたらされます。