PostgreSQLなどのデータベースではなく、RabbitMQなどのメッセージブローカーが必要なのはなぜですか？

私のようなメッセージブローカーに新しいですRabbitMQの私たちのようなスケジューリングシステムのためのタスク/メッセージ・キューを作成するために使用することができますセロリ。

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

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

• なぜ、RabbitMQのように、まったく新しいテクノロジーをセットアップしたいのですか？

PostgreSQLのような私たちのデータベースは分散環境で動作することができるので、今、私はスケーリングが答えではないと信じています。

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

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

では、RabbitMQなどのメッセージブローカーは、これらの問題をどのように解決するのでしょうか。

また、私AMQPはプロトコルがそれに続くものであることを発見しました。その中で何が素晴らしいのですか？

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

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

ウサギのキューはメモリに常駐するため、これをデータベースに実装するよりもはるかに高速です。（良い）専用のメッセージキューは、スロットル/フロー制御などの必須のキュー関連機能や、カップルに名前を付けるためのさまざまなルーティングアルゴリズムを選択する機能も提供する必要があります（ウサギはこれらを提供します）。プロジェクトのサイズによっては、メッセージパッシングコンポーネントをデータベースから分離することもできます。これにより、1つのコンポーネントに大きな負荷がかかった場合でも、他のコンポーネントの動作を妨げる必要がなくなります。

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

• データベースをビジーで低パフォーマンスに保つポーリング：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は、主にメモリ内のKey-Valueストアとして作成されました（現在ではそれよりもはるかに多くの機能があります。スイスのアーミーナイフとも呼ばれます）。それでも、小規模なプロジェクトでRedisを使用して多くの人が良い結果を達成していることを読んだり聞いたりしましたが、大規模なアプリケーションでそれについてあまり聞いたことはありません。

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

PostgreSQL 9.5

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

外部キューイングシステムは引き続き有用であり、缶詰機能、実証済みのパフォーマンス、他のシステムとの統合、水平スケーリングとフェデレーションのオプションなどを提供します。それでも、単純なケースでは、本当にそれらは必要ありません。

古いバージョン

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

そのため、PGQなどのツールが存在します。

LISTENとを使用してPostgreSQLでポーリングを取り除くことができますNOTIFYが、高度な並行処理を維持し、挿入をブロックせずに、キューの先頭から1つのコンシューマーにエントリを確実に渡すという問題は解決されません。あなたが考えるすべての単純で明白な解決策はその問題を実際に解決するものではなく、シングルワーカーのキューフェッチの非効率なバージョンに退化する傾向があります。

高度な並行マルチワーカーキューフェッチが必要ない場合、PostgreSQLで単一のキューテーブルを使用することは完全に合理的です。