(インタビューの質問) メッセージ キューはメッセージ バックログをどのように処理しますか?

1. パフォーマンスを最適化することでメッセージのバックログを事前に防止し、回避します。

メッセージ キューの処理能力は、1 秒あたり数万、さらには数十万のメッセージのレベルに達する可能性があり、ビジネス システムが処理する必要があるビジネス ロジックはメッセージ キューよりも複雑であるため、単一のノードで数百から数十万のメッセージを処理できます。何千ものリクエストを処理できるため、非常に高いパフォーマンスが得られると考えられます。したがって、メッセージ キューのパフォーマンスを最適化するには、ビジネス コードがメッセージの送受信の両端でメッセージ キューとどのように連携して最高のパフォーマンスを達成するかに重点を置きます。

1. 送信側のパフォーマンスの最適化

一般に、送信者は最初に独自のビジネス ロジックを実行してからメッセージを送信する必要があるため、メッセージを送信する送信者のパフォーマンスは比較的低くなります。これは、メッセージを送信する前にビジネス ロジックを実行するのに時間がかかりすぎるためである可能性があります。

(1) ビジネスロジックの実行に時間がかかりすぎる問題をどう解決するか?

適切な同時実行性とバッチ サイズを設定することで、良好な送信パフォーマンスを実現できます。

(2) メッセージを送信するプロセスではどのような手順を考慮する必要がありますか?

Producerメッセージ送信のプロセスは、Producerにメッセージを送信しBroker、Brokerメッセージを受信した後に確認応答を返すという完全な対話です。このインタラクションの平均遅延が 1ms であると仮定します。この 1ms 時間を分解します。これには、次のステップの消費時間が含まれます。

• 送信者がデータを準備し、メッセージをシリアル化し、リクエストやその他のロジックを構築するのにかかる時間は、送信者がネットワーク リクエストを送信するのにかかる時間です。
• ネットワーク上でメッセージを送信し、応答を返すのにかかる時間。
• ブローカーのメッセージ処理の遅延。

単一のスレッドで送信され、一度に 1 つのメッセージのみが送信される場合、1 秒あたり 1000 ミリ秒 / 1 ミリ秒 * 1 / ミリ秒 = 1000 メッセージしか送信できません。この場合、メッセージ キューの強度を最大限に活用することはできません。 。

その後、送信される各メッセージのバッチ サイズを増やすか、同時実行性を高めることで、送信パフォーマンスを 2 倍にすることができます。批量发送 を選択するかどうかについては增加并发、主に送信プログラムのビジネスの性質によって決まります。簡単に言うと、パフォーマンス要件を満たしていれば、好きなように実装できます。

(3) 例

• メッセージの送信先が 1 つの場合微服务、それは主に接收 RPC 请求处理オンライン ビジネスです。もちろん、マイクロサービスが各リクエストを処理するときは、当前线程メッセージを直接送信するだけで済みます。すべての RPC フレームワークはマルチスレッドであり、複数の同時実行をサポートしているため、自然に実装されます并行发送消息。また、オンライン ビジネスはリクエストをより重視しており响应时延、その選択は批量发送必然的に RPC サービスに影響します时延。この場合、并发送信パフォーマンスを向上させるのが賢明な方法です。
• オフライン分析システムの場合、オフライン システムは遅延を気にせず、システム全体のスループットに注意を払います。送信側のデータはすべてデータベースから取得されます。この場合更适合批量发送、データベースからデータをバッチで読み取ることができます。

2. 消費者側のパフォーマンスの最適化

消費速度が生産速度よりも常に遅い場合、長期間にわたってシステム全体に問題が発生します。メッセージ キューのストレージがいっぱいになって処理できなくなるか、メッセージが失われます。

したがって、システムを設計する際には、監視下でシステムが継続的に動作できるように、消費者側の消費性能が生産側の送信性能よりも高いことを保証する必要があります。

消費者のパフォーマンスを向上させる方法

1. 消費ビジネスロジックを最適化する
2. 水平方向の拡張。コンシューマ側の同時実行数を増やして、全体的な消費パフォーマンスを向上させます。
   • コンシューマーの場合、各パーティション (キューとも呼ばれます) はシングルスレッドの使用のみをサポートできるため、インスタンスの数を拡張するときは、トピック内のパーティションの数Consumerも同時に拡張する必要があります。Consumer等しい。Consumerインスタンスの数がパーティションの数を超える場合、そのような拡張は実際には効果がありません。
     
     
3. メッセージをメモリ キューに入れると、応答を迅速に返すことができ、メッセージを処理するビジネス スレッドは並列消費を実現し、システムのスループットとパフォーマンスを向上させ、単一のメッセージを並列で消費できない問題を解決できます Consumer。
   
   

2. オンライン システムにメッセージのバックログがあります。緊急に対処するにはどうすればよいですか?

1. メッセージバックログの原因を分析する

(1) メッセージ バックログの発生に関しては、大まかな原因は次の 2 つだけです。

1. メッセージの送信が速くなります
2. システムの消費が遅くなる

(2) 一般的な理由は大きく 3 つあります。

1. タスクが生成するサービスが多すぎ、タスクが処理するサービスが少なすぎるため、バランスが崩れています。
2. タスクの処理時間が長すぎるため、過剰生産にもつながります。
3. ミドルウェア自体の容量は小さいため、拡張またはクラスター管理が必要です。

2. 問題を解決する

流量控制
(1) ( 2)扩容消费端实例全体的な消費能力を向上させるためにタスクの生成を監視します
(3)系统降级重要でないビジネスをいくつか閉鎖し、送信者によって送信されるデータ量を削減します
(4) 消費が遅くなりました、わかりました检查日志、大規模な消費エラーがないか確認します; スレッドが卡在什么地方移動していないかどうかを確認できます。たとえば、リソースを待機しているか、デッドロックが発生しているかどうかを確認できます。

3. 参考資料

1. メッセージ キュー マスター コース
2. アーキテクチャ設計 | 非同期処理プロセス、複数の実装モードの詳細説明