RabbitMQ：セロリはピカが提供しないものを提供しますか？
私は、RabbitMQを介していくつかの分散タスクを機能させることに取り組んできました。
セロリにやりたいことをやらせようとしばらく時間を費やしましたが、うまくいきませんでした。
それから私はピカを使ってみました、そして物事は完璧にそして数分以内にうまくいきました。
セロリの代わりにピカを使って見逃しているものはありますか？
Pikaが提供するのは、Celeryが行っていることのほんの一部です。 PikaはPython RabbitMQと対話するためのライブラリです。RabbitMQはメッセージブローカーです。基本的には、キューとの間でメッセージを送受信するだけです。タスクキューとして使用できますが、また、実際に「作業」を配布せずに、プロセス間でメッセージを渡すために使用することもできます。
Celeryは分散タスクキューを実装し、オプションでRabbitMQをIPCのブローカーとして使用します。プロセス間でメッセージを送信する方法を提供するだけでなく、プロセス間で実際のタスク/ジョブを分散するためのシステムを提供します。 Celeryのサイトでの説明は次のとおりです。
タスクキューは、スレッドまたはマシン間で作業を分散するためのメカニズムとして使用されます。
タスクキューの入力は、タスクと呼ばれる作業単位であり、専用のワーカープロセスは、実行する新しい作業についてキューを常に監視します。
セロリはメッセージを介して通信し、通常はブローカーを使用してクライアントとワーカーの間を仲介します。クライアントがメッセージをキューに入れるタスクを開始するために、ブローカーはメッセージをワーカーに配信します。
Celeryシステムは、複数のワーカーとブローカーで構成でき、高可用性と水平スケーリングに道を譲ります。
セロリには、ピカの範囲外の機能がたくさん組み込まれています。 Celery docs を見て、実行できることの種類を理解できますが、例を次に示します。
_>>> from proj.tasks import add
>>> res = add.chunks(Zip(range(100), range(100)), 10)()
>>> res.get()
[[0, 2, 4, 6, 8, 10, 12, 14, 16, 18],
[20, 22, 24, 26, 28, 30, 32, 34, 36, 38],
[40, 42, 44, 46, 48, 50, 52, 54, 56, 58],
[60, 62, 64, 66, 68, 70, 72, 74, 76, 78],
[80, 82, 84, 86, 88, 90, 92, 94, 96, 98],
[100, 102, 104, 106, 108, 110, 112, 114, 116, 118],
[120, 122, 124, 126, 128, 130, 132, 134, 136, 138],
[140, 142, 144, 146, 148, 150, 152, 154, 156, 158],
[160, 162, 164, 166, 168, 170, 172, 174, 176, 178],
[180, 182, 184, 186, 188, 190, 192, 194, 196, 198]]
_このコードは、xがrange(0, 100)にあり、yがrange(0,100)にあるすべてのx + yを追加したいと考えています。これは、2つの数値を加算するaddというタスクを実行し、_1+1_、_2+2_、_3+3_などを10個のチャンクに追加する作業を分散することによって行われます。 、および各チャンクを利用可能な数のCeleryワーカーに配布します。各ワーカーは、すべての作業が完了するまで、10アイテムのチャンクでaddを実行します。次に、結果はres.get()呼び出しによって収集されます。ピカを使ってこれを行う方法を想像できると思いますが、どれだけの作業が必要になるかも想像できると思います。 Celeryを使用すると、その機能をすぐに利用できます。
必要に応じて、特に非常に単純なユースケースがある場合は、pikaを使用して分散タスクキューを実装できます。 Celeryは、タスクのスケジューリングや管理などのための「バッテリーを含む」ソリューションを提供しているだけです。これは、pikaソリューションで必要になる場合は、手動で実装する必要があります。
私が思うこの答えに基づいて、誰かが必要のないときにセロリを勧めたのは今日が2回目なので、ここに答えを追加します。したがって、分散タスクキューとブローカーの違いは、ブローカーがメッセージを渡すだけであるということです。それ以上でもそれ以下でもありません。 Celeryは、RabbitMQをIPCのデフォルトのブローカーとして使用し、そのアダプターの上に配置して、デーモンプロセスでタスク/キューを管理することをお勧めします。これは、一般的なものが非常に迅速に必要な分散タスクに特に役立ちます。 。これは、発行者/消費者プロセスの構成にすぎません。特定のニーズに基づいてステップスルーし、メッセージの耐久性を確保するために必要なワークフローを定義した実際のタスクでは、セロリに依存するよりも、独自の発行者/消費者を作成する方がよいでしょう。 。明らかに、耐久性チェックなどをすべて行う必要があります。ほとんどのWeb関連サービスでは、実際の「作業」ユニットを制御するのではなく、サービスに渡します。したがって、分散タスクキューにはほとんど意味がありません。 ip/geographical regionまたはaccountnumber ...またはそれらの線に沿った何かに基づいて任意のAPI呼び出し制限に達していない限り、セロリを使用しても、状態コードまたはworの管理を記述または処理する必要がなくなりません。 kflowなどを使用すると、パブリッシャー/コンシューマーコードの構成を記述しないようにする方法でAMQPが公開されます。
つまり、作業をかみ砕くために単純なタスクキューが必要であり、パフォーマンスの微妙な違い、ワークフロー全体の耐久性の複雑さ、または実際の公開/消費プロセスについてあまり心配していない場合です。セロリは動作します。実際に制御していないAPIまたはサービスにメッセージを渡すだけの場合は、確かに、Celeryを使用できますが、数分でPikaを使用して独自のパブリッシャー/コンシューマーを簡単に作成できます。堅牢なもの、または独自の耐久性シナリオに準拠したものが必要な場合は、他のすべての人と同じように独自の公開/コンシューマーコードを記述してください。