それらの違いは何だろうか。彼らは同じことを説明していますか?
Google App Engineサービスタスクキューはメッセージキューの実装ですか?
それらの違いは何だろうか。彼らは同じことを説明していますか?
Google App Engineサービスタスクキューはメッセージキューの実装ですか?
Facebookのいくつかの開発者コミュニティグループで同様の質問をしました。特にGoogleAppEngineについてではありませんでした。私は、より一般的な意味で、RabbitMQとCeleryの間のユースケースを決定するように依頼しました。これが私が得た回答で、トピックに関連していると思います。メッセージキューとタスクキューの違いをかなり明確にしています。
私は尋ねた:
「Celeryは、内部のqueueManagement /queueAdministrationアクティビティなどを管理する必要があるという複雑さを取り除くQueueWrapper/QueueFrameworkです」と言うのは適切でしょうか?
「Celeryはタスクキューです」と「RabbitMQはメッセージブローカーです」という本の言葉を理解しています。ただし、RabbitMQが「キュー」であることが常にわかっているため、初めてのセロリユーザーとしては少し混乱しているようです。
ウサギMQと対照的にセロリがどのように/何をするかを説明するのを手伝ってください
アブ・アシュラフ・マスヌンからの返事
タスクキューとメッセージキュー。RabbitMQは「MQ」です。メッセージを受信し、メッセージを配信します。
セロリはタスクキューです。関連データとともにタスクを受け取り、実行して結果を提供します。
セロリをちょっと忘れましょう。RabbitMQについて話しましょう。私たちは通常何をしますか?Django/Flaskアプリはメッセージをキューに送信します。特定のキューで新しいメッセージを待機するワーカーを実行します。新しいメッセージが到着すると、メッセージは機能を開始し、タスクを処理します。
セロリはこのプロセス全体を美しく管理します。AMQPやRabbitMQの詳細について学習したり心配したりする必要はもうありません。メッセージブローカーとして、Redisまたはデータベース(MySQLなど)を使用できます。Celeryを使用すると、ワーカーコードを使用して「タスク」を定義できます。バックグラウンド(またはフォアグラウンド)で何かを実行する必要がある場合は、このタスクを呼び出すか(即時実行の場合)、処理を遅らせるようにこのタスクをスケジュールできます。Celeryは、メッセージの受け渡しとタスクの実行を処理します。定義されたタスクを実行して結果を保存する方法を知っているワーカーを起動します。したがって、後で必要に応じてタスクの結果やタスクの進行状況を照会できます。
cronジョブの代わりにCeleryを使用することもできます(私はそれが本当に好きではありませんが)!
Juan FranciscoCalderonZumbaから受け取った別の応答
私の理解では、セロリはイベントのプロデューサー/コンシューマーを実装するための非常に高レベルの抽象化にすぎません。たとえばrabbitmqで作業するために必要ないくつかの苦痛なことを取り除きます。セロリ自体はキューではありません。イベントキューは選択したシステムに保存されます。セロリは、プロデューサー/コンシューマーを最初から作成しなくても、そのようなイベントを処理するのに役立ちます。
最終的に、これが私の最終的な学習として持ち帰ったものです。
Celeryはキューラッパー/フレームワークであり、RabbitMQの直接操作に伴う基盤となるAMQPメカニズム/アーキテクチャを管理する必要があるという複雑さを取り除きます。
GAEのタスクキューは、アプリケーションがバックグラウンド処理を実行できるようにするための手段であり、メッセージキューと同じ目的を果たすことはありません。それらは、異なる機能を果たす非常に異なるものです。
メッセージキューは、プロセス、スレッド、システム間で情報を共有するためのメカニズムです。
AppEngineタスクキューは、AppEngineアプリケーションがそれ自体に言う方法です。これを行う必要がありますが、クライアントリクエストのコンテキスト外で、後で行います。
コンテキストによって異なる場合がありますが、以下は私の理解です。
メッセージキューはメッセージブローカーの一部であり、キューデータ構造の実装であり、次のことができます。
一方、タスクキューは、タスクを処理するためのものです。
ご覧のとおり、メッセージキューとタスクキューは異なる側面に焦点を合わせており、重複する可能性がありますが、必ずしもそうとは限りません。
メッセージキューではなくタスクキューの例-タスクが順序を気にしない場合-各タスクは相互に依存しません-「キュー」のFIFOデータ構造は必要ありません。できますが、そうする必要はありません。プール、単純なSQL / NoSQLデータベース、またはS3のようなバッファリングされたタスクを格納する場所が必要なだけです。
反対の例はプッシュ通知です。メッセージキューを使用しますが、必ずしもタスクキューである必要はありません。サーバーはイベント/通知を生成し、それらをクライアントに配信したいと考えています。サーバーは通知をキューにプッシュします。クライアントは、準備ができたときにキューから通知を消費/プルダウンします。これには、GCP PubSub、AWSSNSなどの製品を使用できます。
タスクキューは通常、同時実行制御のためにメッセージキューよりも複雑です。もちろん、ノード間でワーカーを分散して同時実行を最適化するような水平スケーリングが必要な場合は言うまでもありません。
Celeryのようなツールは、タスクキューとメッセージキューを1つにまとめたものです。私が知っているように、両方を実行するCeleryのようなツールは多くありません。そのため、Celeryが非常に人気があると思います(代替手段はNodeJSのBullまたはBeeです。詳細については、お知らせください)。
私の会社は最近、タスクキューを実装する必要がありました。適切なツールを探している間、これらの2つの用語は私を非常に混乱させました。なぜなら、私は自分が何を求めているのかはある程度知っているのですが、人々がそれをどのように呼んで、どのキーワードで検索すべきかわからないからです。
個人的にはAppEngineをあまり使ったことがないので答えられませんが、上記の点をいつでもチェックして、要件を満たしているかどうかを確認できます。
機能についてだけ話すと、違いを見分けるのは難しいでしょう。私の会社では、両者の誤解により惨めに失敗します。ワーカーキュー(別名タスクキュー、別名スケジューラ、別名cron)を作成し、それを長時間のポーリングに使用します。ポーリングコードをトリガーするために、タスクスケジュールを5秒先(遅延)に設定しました。コードはリクエストを起動し、レスポンスをチェックします。条件が満たされない場合は、ポーリングを延長し、それ以外の場合は延長しないタスクを再度作成します。これはDB、ネットワークであり、計算量が多くなります。私たちの新しいユースケースでは、迅速な対応が必要であり、遅延を0.1に減らす必要があります。これは、ポーリングごとに多くの無駄があります。つまり、これはテクノロジーが同じ目標を達成するが、同じ習熟度を達成しないという典型的な例です。したがって、主な違いは、メッセージキューとタスクキューが達成しようとする目標にあります。よく読んでください: https://stackoverflow.com/a/32804602/3422861
ブラウザのJavaScriptランタイム環境またはNodejsJavaScriptランタイム環境の観点から考えると、答えは次のとおりです。
メッセージキューとマイクロタスクキュー( Promisesなど)の違いは、マイクロタスクキューの優先度がメッセージキューよりも高いことです。つまり、マイクロタスクキュー内のPromiseタスクは、内部のコールバックの前に実行されます。メッセージキュー。