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