私はRabbitmq(およびプログラミング)の初心者なので、これが明らかな場合は事前に申し訳ありません。キューで動作しているスレッド間で共有するプールを作成していますが、プールで接続またはチャネルを使用する必要があるかどうかわかりません。
実際の作業を行うためにチャネルが必要であることはわかっていますが、接続ごとに 1 つのチャネルを使用することで (キューからのスループットが向上するという点で) パフォーマンス上の利点はありますか? それとも、アプリケーションごとに 1 つの接続を使用し、多くのチャネルをプールする方がよいでしょうか?
注: 私はリソースをプールしているので、接続はチャネルよりも高価であることを知っているので、初期コストは要因ではありません。私はスループットにもっと興味があります。
これはrabbitmq Webサイトで見つけたので、下の関連部分を引用しました。
tl;dr バージョンでは、アプリケーションごとに 1 つの接続と、スレッドごとに 1 つのチャネルが必要です。それが役立つことを願っています。
接続
通常、AMQP 接続は長期間有効です。AMQP は、信頼性の高い配信のために TCP を使用するアプリケーション レベルのプロトコルです。AMQP 接続は認証を使用し、TLS (SSL) を使用して保護できます。アプリケーションが AMQP ブローカーに接続する必要がなくなった場合、基になる TCP 接続を突然閉じるのではなく、AMQP 接続を適切に閉じる必要があります。
チャネル
一部のアプリケーションでは、AMQP ブローカーへの複数の接続が必要です。ただし、多数の TCP 接続を同時に開いたままにしておくことは望ましくありません。これを行うと、システム リソースが消費され、ファイアウォールの構成がより困難になります。AMQP 0-9-1 接続は、「単一の TCP 接続を共有する軽量接続」と考えることができるチャネルで多重化されます。
処理に複数のスレッド/プロセスを使用するアプリケーションの場合、スレッド/プロセスごとに新しいチャネルを開き、それらの間でチャネルを共有しないことは非常に一般的です。
特定のチャネルでの通信は、別のチャネルでの通信とは完全に分離されているため、すべての AMQP メソッドにはチャネル番号も含まれており、クライアントはそのメソッドがどのチャネル用であるか (つまり、どのイベント ハンドラを呼び出す必要があるかなど) を特定するために使用します。 .
スレッド セーフであっても、スレッドごとに 1 つのチャネルを使用することをお勧めします。そのため、1 つのチャネルを介して複数のスレッドを送信できます。ただし、アプリケーションに関しては、スレッドごとに 1 つのチャネルを使用することをお勧めします。
さらに、チャネルごとに 1 つのコンシューマーのみを持つことをお勧めします。
これらはガイドラインにすぎないため、テストを行って、何が最適かを確認する必要があります。
このスレッドには、こことここにいくつかの洞察があります。
これらすべてのガイドラインにもかかわらず、この投稿は、複数の接続を使用してもパフォーマンスに影響しない可能性が高いことを示唆しています. クライアント側とサーバー（rabbitmq）側のどちらについて話しているのかは特定されていませんが。もちろん、より多くの接続でより多くのシステムリソースを使用するという1つのポイントがあります. これが問題ではなく、より多くのスループットが必要な場合は、この投稿のように複数の接続を使用することをお勧めします複数の接続により、より多くのスループットが可能になることを示唆しています。その理由は、複数のチャネルがあっても、一度に 1 つのメッセージしか接続されないためと思われます。したがって、大きなメッセージが接続全体をブロックするか、1 つのチャネルの多くの重要でないメッセージが同じ接続で別のチャネルの重要なメッセージをブロックする可能性があります。ここでもリソースが問題です。1 つの接続ですべての帯域幅を使い果たしている場合、追加の接続を追加しても、1 つの接続に 2 つのチャネルを使用するよりもパフォーマンスが向上しません。また、各接続はより多くのメモリ、CPU、およびファイルハンドルを使用しますが、スケーリング時には問題になる可能性がありますが、それは問題ではないかもしれません.
受け入れられた答えに加えて：
前にロードバランサがある、または存続期間の短い DNS (毎回異なるウサギ ノードに接続できるようにする) を備えた RabbitMQ ノードのクラスタがある場合、単一の存続期間の長い接続は、1 つの接続を意味します。アプリケーション ノードは、単一の RabbitMQ ノードで排他的に動作します。これにより、1 つの RabbitMQ ノードが他のノードよりも頻繁に使用される可能性があります。
上記のもう 1 つの懸念事項は、パブリッシングとコンシュームが操作をブロックしているため、メッセージがキューに入れられることです。より多くの接続を持つことで、1. 各メッセージの処理時間が他のメッセージをブロックしないこと、2. 大きなメッセージが他のメッセージをブロックしないことが保証されます。
そのため、接続プールを小さくすることを検討する価値があります (上記のリソースに関する懸念を念頭に置いてください)。