245

Celeryのようなスケジューリング システムのタスク/メッセージ キューを作成するために使用できるRabbitMQのようなメッセージ ブローカーは初めてです。

さて、ここに質問があります：

  • 新しいタスクを追加して、Celery などのコンシューマ プログラムで使用できるテーブルをPostgreSQLに作成できます。

  • いったいなぜ、RabbitMQ のようなまったく新しい技術をセットアップしたいのでしょうか?

現在、PostgreSQL のようなデータベースは分散環境で機能するため、スケーリングが答えになるとは思えません。

データベースが特定の問題に対してどのような問題を引き起こすかをグーグルで調べたところ、次のことがわかりました。

  • ポーリングはデータベースをビジー状態にし、パフォーマンスを低下させます
  • テーブルのロック -> 再び低パフォーマンス
  • 数百万行のタスク -> 繰り返しますが、ポーリングのパフォーマンスは低いです

さて、RabbitMQ やその他のメッセージ ブローカーは、これらの問題をどのように解決するのでしょうか?

AMQPまた、プロトコルが次のとおりであることもわかりました。その中で何が素晴らしいのですか？

Redisはメッセージ ブローカーとしても使用できますか? RabbitMQ よりも Memcached に似ていると思います。

これに光を当ててください！

4

2 に答える 2

131

Rabbit のキューはメモリ内にあるため、これをデータベースに実装するよりもはるかに高速です。(適切な) 専用のメッセージ キューは、スロットリング/フロー制御などの重要なキューイング関連の機能、およびさまざまなルーティング アルゴリズムを選択する機能も提供する必要があります (うさぎはこれらを提供します)。プロジェクトのサイズによっては、メッセージ パッシング コンポーネントをデータベースから分離することもできます。これにより、一方のコンポーネントに大きな負荷がかかっても、他方の操作を妨げる必要がなくなります。

あなたが言及した問題については：

  • ポーリングはデータベースをビジー状態に保ち、パフォーマンスを低下させます。Rabbitmq を使用すると、プロデューサーは更新をコンシューマーにプッシュできます。これは、ポーリングよりもはるかにパフォーマンスが高いです。データは必要なときに消費者に送信されるだけで、無駄なチェックが不要になります。

  • テーブルのロック -> 再び低パフォーマンス:ロックするテーブルがありません:P

  • 数百万行のタスク -> 再びポーリングのパフォーマンスが低い:前述のように、Rabbitmq は RAM に常駐し、フロー制御を提供するため、より高速に動作します。必要に応じて、RAM が不足した場合にメッセージを一時的に保存するためにディスクを使用することもできます。2.0 以降、Rabbit の RAM 使用量は大幅に改善されました。クラスタリング オプションも利用できます。

AMQP に関して言えば、本当に優れた機能は「交換」であり、他の交換にルーティングできる機能です。これにより柔軟性が向上し、スケーリング時に非常に便利な、さまざまな精巧なルーティングの類型を作成できます。良い例については、次を参照してください。


(出典: springsource.com )

および: http://blog.springsource.org/2011/04/01/routing-topologies-for-performance-and-scalability-with-rabbitmq/

最後に、Redis に関しては、はい、メッセージ ブローカーとして使用でき、うまく機能します。ただし、Rabbitmq は完全な機能を備えたエンタープライズ レベルの専用メッセージ キューとしてゼロから構築されたため、Rabbitmq には Redis よりも多くのメッセージ キューイング機能があります。一方、Redis は主にメモリ内のキーと値のストアとして作成されました (ただし、現在はそれ以上の機能を備えています。スイス アーミー ナイフと呼ばれることさえあります)。それでも、小規模なプロジェクトで Redis を使用して良い結果を達成している多くの人々を読んだり聞いたりしましたが、大規模なアプリケーションではそれについてあまり聞いたことがありません。

以下は、ロングポーリング チャットの実装で使用されている Redis の例です: http://eflorenzano.com/blog/2011/02/16/technology-behind-convore/

于 2012-10-22T06:33:53.230 に答える
77

PostgreSQL 9.5

PostgreSQL 9.5 には が組み込まれていSELECT ... FOR UPDATE ... SKIP LOCKEDます。これにより、機能するキュー システムの実装がはるかに単純かつ容易になります。他のセッションがロックしていない「n」行をフェッチし、作業が完了したことを確認するまでロックしたままにすることが簡単になったため、外部のキューイング システムは必要なくなりました。外部調整が必要な場合は、2 フェーズ トランザクションでも機能します。

外部キューイング システムは引き続き有用であり、既定の機能、実証済みのパフォーマンス、他のシステムとの統合、水平方向のスケーリングとフェデレーションのオプションなどを提供します。

古いバージョン

そのようなツールは必要ありませんが、ツールを使用すると生活が楽になる場合があります。データベースでキューイングを行うのは簡単に見えますが、実際には、高性能で信頼性の高い同時キューイングをリレーショナル データベースで正しく行うのは非常に難しいことがわかります。

PGQのようなツールが存在するのはそのためです。

LISTENandを使用して PostgreSQL でのポーリングを取り除くことはできますがNOTIFY、高度な同時操作を維持し、挿入をブロックせずに、キューの一番上にあるエントリを正確に 1 つのコンシューマーに渡すという問題は解決しません。その問題を解決すると思われるシンプルで明白な解決策はすべて、実際には現実の世界では解決されず、シングルワーカーキューフェッチの非効率的なバージョンに退化する傾向があります。

高度な同時マルチワーカー キュー フェッチが必要ない場合は、PostgreSQL で単一のキュー テーブルを使用することはまったく合理的です。

于 2012-10-22T05:42:35.060 に答える