現在、私はいくつかのバックグラウンドジョブ（主に電子メールの送信と重いデータベースの更新）を実装する必要があるpythonプロジェクトに取り組んでいます。私はタスクブローカーのためにRedisを使用します。この点で私はCeleryとRQという2つの候補を持っています。私はこれらのジョブキューでいくつかの経験を持っていましたが、私はあなたにあなたがこのツールを使用する経験を共有するように頼んでみたいです。そう。長所と短所Celery対RQを使用する
セロリはかなり複雑に見えますが、それは完全な機能を備えたソリューションです。実際に私はこれらの機能がすべて必要とは思わない。反対側のRQが（例えばコンフィギュレーション、統合）非常にシンプルですが、それはいくつかの便利な機能が欠けているようだから、（例えば、タスク取り消し、コードの自動リロード）
これはまったく同じ質問に答えるために私が見つけたものです。おそらく包括的ではなく、ある点では不正確かもしれません。
簡潔に言えば、RQはすべての場所でより簡単に設計されています。セロリはより強固になるように設計されています。どちらも優れています。
監視を内部化するためにあまりにも多くのオプションがあるようなものを設定しているとき、それをかなり多くを再訪問することを期待しています。 Celery's FlowerとRQ dashboardは、設定が非常に簡単で、必要とするすべての情報の90％以上を提供します。
ブローカーのサポート。セロリは明白な勝者ですが、RQはレディスのみをサポートします。これは「ブローカーとは何か」に関する資料の数が少なくなることを意味しますが、Redisがもはやあなたのために働かなくても、将来ブローカーを切り替えることはできません。たとえば、Instagram considered both Redis and RabbitMQ with Celeryです。異なるブローカーの保証が異なるため、これは重要です。レディス（書面による）保証はあなたのメッセージが配信される100％できません。
優先度キュー。 RQの優先度キューモデルはシンプルで効果的です - workers read from queues in order。セロリは、異なるキューから消費する複数のワーカーを必要とします。両方のアプローチが動作します
OSサポート。セロリはここではっきりと勝者です.RQはforkをサポートするシステム上でのみ実行されるためです。 Unixシステム
言語サポート。セロリは、あなたが別の言語に
APIを一つの言語からタスクを送信することができます一方、RQは、Pythonのをサポートしています。セロリは非常に柔軟性があります（複数の結果バックエンド、素敵な設定フォーマット、ワークフローキャンバスサポート）が、当然ながらこのパワーは混乱することがあります。対照的に、RQ apiは単純です。
サブタスクのサポート。セロリはサブタスクをサポートしています（既存のタスク内から新しいタスクを作成するなど）。 RQがわからない場合は
コミュニティと安定性。セロリはおそらくより確立されていますが、どちらもアクティブなプロジェクトです。 RQがありながら、執筆時点で、セロリは〜2000〜Githubの上の3500星を持ち、両方のプロジェクトは、私の意見では積極的な開発
を示し、セロリは、その評判は信じるようにあなたを導くかもしれないほど複雑ではありませんが、あなたは意志RTFMする必要があります。
だから、なぜ誰かが（おそらくもっとフル機能を備えた）セロリーをRQのために貿易したいのですか？私の心の中で、それはすべて単純さに帰ります。 Redus + Unixに自身を限定することで、RQはより簡単な文書、より簡単なコードベース、より簡単なAPIを提供します。これは、作業中のメモリにタスクキューシステムの詳細を保存する代わりに、あなた（そしてあなたのプロジェクトへの貢献者）が気になるコードに集中できることを意味します。私たちには、どれだけ多くの細部が一度にできるのかには限界があり、そこにタスクキューの詳細を保持する必要性を取り除くことで、気になるコードに戻ることができます。その単純さは、言語間タスクキュー、幅広いOSサポート、100％信頼性のあるメッセージ保証、メッセージブローカーの簡単な切り替えなどの機能を犠牲にしています。
セロリは、その複雑ではありません。そのコアでは、tutorialsからステップコンフィグレーションを行い、celeryインスタンスを作成し、関数を@celery.taskで飾り、次にmy_task.delay(*args, **kwargs)でタスクを実行します。
あなた自身の評価から判断すると、（キー）機能が不足しているか、余分なものがあるかを選択する必要があるようです。それは私の本ではあまりにも難しい選択肢ではありません。
私はあなたの評価に完全に同意しません。私はドキュメンテーションと多くのブログ記事の多くを読んだ後でも、Debianサーバー上でセロリをうまく動かすために2,3週間苦労しました。私が持っていた主な問題は、あなたの設定が間違っていたら、Celeryは問題が何であるかに関するフィードバックを*提供しないということでした。私はついにそれを動かすと、セロリのスタックにいくつかのタイプのOSErrorを深く入れ始めました。私はGithubに問題を掲載しましたが、誰も助けることはできませんでした。私は10フィートのポールでセロリに再び触れないだろう。 – William
残念ながら、この種の質問はこのサイトのフォーマットに適合しません。[FAQ＃dontask]を参照してください。このような質問は、あまりにも時代遅れの曖昧な回答につながる傾向があります。特定の問題についてお手伝いできる場合は、別の質問を投稿してください。 –
私はあなたがタスクを取り消すことができるようです.RQダッシュボードの場合でも、 –