RabbitMQでスループットを最大化
このプロジェクトでは、「タスクキュー」パターンでRabbitMQを使用してデータを渡します。
プロデューサー側では、いくつかのTCP server（node.js））を作成して、同時並行データを受信し、何もせずにMQに送信します。
コンシューマー側では、Java clientを使用してMQからタスクデータを取得し、それを処理してからackします。
したがって、問題は次のとおりです。最大メッセージ通過スループット/パフォーマンス（たとえば、400,000 msg /秒）を取得するには、最適なキューの数はいくつですか。キューが増えると、スループット/パフォーマンスが向上しますか？そして、他に気をつけるべきことはありますか？そのようなシナリオでRabbitMQを使用するための既知のベストプラクティスガイドはありますか？
コメントは大歓迎です!!
RabbitMQで最高のパフォーマンスを得るには、作成者のアドバイスに従ってください。 RabbitMQブログ から：
RabbitMQのキューは、空のときに最も高速です。キューが空で、コンシューマーがメッセージを受信する準備ができている場合、メッセージはキューによって受信されるとすぐに、コンシューマーに直接送信されます。永続キューの永続メッセージの場合、はい、それもディスクに送られますが、これは非同期に行われ、大量にバッファーされます。主なポイントは、実行する必要のあるブックキーピングがほとんどないこと、変更されるデータ構造がほとんどないこと、および追加のメモリを割り当てる必要がほとんどないことです。
RabbitMQキューのパフォーマンスを深く掘り下げたい場合は、この 他のブログエントリ を使用して、さらにデータを調べます。
私がrabbitmq-discussメーリンググループから一度受け取った応答によると、スループットを増やして待ち時間を減らすために試すことができる他のことがいくつかあります：
より大きなプリフェッチ数を使用します。値が小さいとパフォーマンスが低下します。
トピック交換は、直接交換またはファンアウト交換よりも時間がかかります。
キューが不足しないようにしてください。キューが長いほど、処理オーバーヘッドが大きくなります。
レイテンシとメッセージレートを重視する場合は、小さいメッセージを使用します。効率的な形式を使用するか（XMLを回避するなど）、ペイロードを圧縮します。
パフォーマンスに役立つHiPEを試してください。
トランザクションと永続性を避けます。また、即時モードまたは必須モードでの公開は避けてください。 HAを避けます。クラスタリングもパフォーマンスに影響を与える可能性があります。
複数のキューとコンシューマーがある場合、マルチコアシステムでスループットが向上します。
フロー制御が導入されたv2.8.1以降を使用してください。メモリとディスク容量のアラームがトリガーされないことを確認してください。
仮想化により、パフォーマンスが少し低下する可能性があります。
OSとネットワークスタックを調整します。十分なRAMを提供してください。高速コアとRAMを提供します。
プリフェッチ数を増やし、同時にコンシューマーから複数のメッセージにACK（メッセージごとにACKを送信するのではなく）することで、スループットが向上します。
ただし、もちろん、複数のフラグをオンにしたACK（ http://www.rabbitmq.com/amqp-0-9-1-reference.html#basic.ack ）は、コンシューマで追加のロジックを必要としますアプリケーション（ http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2013-August/029600.html ）。ブローカーから配信されたメッセージの配信タグのリスト、それらのステータス（アプリケーションがメッセージを処理したかどうか）、およびすべての配信メッセージがある場合はN番目ごとの配信タグ（NDTAG）にACKを送信する必要があります。 -NDTAG以下のタグが処理されました。