私たちのプロジェクトでは、「タスク キュー」パターンで RabbitMQ を使用してデータを渡したいと考えています。
プロデューサ側では、いくつかの TCP サーバー (node.js 内) を構築して、大量の同時データを受信し、何もせずに MQ に送信します。
コンシューマ側では、JAVA クライアントを使用して MQ からタスク データを取得し、それを処理してから確認します。
問題は、最大のメッセージ パッシング スループット/パフォーマンス (たとえば、400,000 メッセージ/秒) を取得するには、キューの数が最適かどうかです。キューが増えるということは、スループット/パフォーマンスが向上するということですか? 他に注意すべきことはありますか？このようなシナリオで 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 以下のタグが処理されました。