17

かなり多くのメディア処理 (画像、ビデオ) や電子メール出力などを含む大規模なプロジェクトが近日中に予定されています。通常は「email_queue」と呼ばれるテーブルに入れるようなもので、cron を使用してスクリプトは、テーブル内のキューを処理します。

私は、beanstalkd のようなメッセージ キュー システムについて多くのことを読んでおり、それをセットアップしたことさえあります。簡単で使いやすかったです。問題は、何かが足りないかどうかわからないことです。

テーブルと CRON ではなく、キュー システムを使用する利点を詳しく説明してもらえますか? 私は本当に彼らが何であるかを見ることができないので。

ありがとう

4

4 に答える 4

22

違い:

  1. メッセージがキューに入れられると、すぐに配信できます。したがって、cron が通常 5 分ごとに実行される場合は、キューイングを使用して処理を高速化できます。

  2. キューイング システムがトランザクションをサポートしている場合、処理が失敗した場合、自動的にメッセージが再配信されます。

  3. キューにあるものを照会するのが難しくなる可能性があります。データベース テーブルには、優れた検索方法 (sql) があります。

  4. メッセージを処理するサーバー/プロセス/スレッドが複数ある場合、キュー システムは、メッセージがそのうちの 1 つだけに配信されるようにします。DB テーブルでは、アプリケーション コード (ロック、フラグなど) を介してこれを処理する必要があります。

于 2009-12-03T15:38:02.980 に答える
6

メッセージ キュー (少なくとも分散型のもの、たとえばRabbitMQ ) を使用すると、物理ノード間で作業を分散できます。作業をデキューして処理するには、各ノードにプロセスが必要です。

それは最終的にあなたの要件に帰着します。メッセージ キューを使用すると、より管理しやすいソリューションを大規模に実現できます。ノードをより簡単に切り離すことができます。

もちろん、学習曲線があります...つまり、再び目標に戻ります。

各ノードでは、実装を変更するまで (および変更する場合) cron/db テーブルを再利用できることに注意してください。 これが、可能な場合のデカップリングの優れた点です。

于 2009-12-03T15:36:20.283 に答える
4

まず、キューは多くの場合、実際の DB テーブルに支えられており、メッセージの耐久性を維持できます。それはさておき、キューは、非同期で実行する必要がある作業を押しのけるための自然な方法です。最初からそのプリンシパルで設計すると、キューは非常に強力です。

テーブル (エンティティ) がハード列 (属性) のセットを持っているという事実を除けば、このテーブルは構成するレコードのセットで構成されているだけでなく、キューももののリストに過ぎません。 -a-table を正式なキューとして、定期的に (cron) ベースでポーリングしているだけです。

MQ は、通常、メッセージ自体へのアクセスを同期するという別の気の利いた機能を追加します (次のものを取得するために SQL でこれを行う場合と行わない場合があります)。

私は cron/table メカニズムを POLL ベース、MQ を EVENT ベースと考えるのが好きです。

私の意見では、キューの利点は、同期とステータスの更新を処理できることです。MQ は、「ブロードキャスト」(トピック) するように設定したり、コンシューマーまたはリスナーのグループにメッセージを提供したりできます。

MQ は非同期ですが、cron ウィンドウ間で動作する可能性があります。テーブルで処理するメッセージの数が、次の cron ジョブが実行されて前のジョブを実行しようとする前に達成できることをどのように知ることができますか?

MQ の複数のコンシューマーにより、必要に応じて作業をスケーリングできます。上記の例で、load average(OS のプロセス キューとまったく同じ) が希望よりも大きいことがわかった場合は、別のコンシューマーをプロビジョニングして、その負荷を処理し、メトリックの要求に応じてオンまたはオフラインにすることができます。

MQ は、メッセージの優先度やパフォーマンスなどのさまざまな運用パラメーターを持つように設定できます (一部のキューはメモリに保持でき、その他はディスクに保持できます)。

欠点は、(既に述べたように) キューのクエリやメトリックの取得が難しい場合があることです。SQL でキューを自分で監視できるように、DB バッキング ストアを備えた MQ システムを常に見つけます。

于 2009-12-15T05:56:52.920 に答える
1

これはかなり頻繁に尋ねられます。データベースに慣れている場合は、通常、MQを使用する理由はありません。これがスレッドの例です。

私の考えでは、データ要件に非常に大量のデータが含まれていない限り、学習曲線を避けたいと思うかもしれません。これは、タイマー付きのプロセスではなくcronである場合はほとんどありません（タイマー付きの複数のプロセスははるかに少ないです）。

于 2009-12-15T06:04:44.340 に答える