メッセージのバックログのためにまず、理由
メッセージのバックログの直接の原因は、システムがなければなりませんパフォーマンスの問題の一部、上流送信されたメッセージを処理する時間は、メッセージのバックログを引き起こすことはないでしょう。
第二に、メッセージのバックログを回避するために、パフォーマンスを最適化
システムでは、主に、最適なパフォーマンスのために、メッセージキューを使用して二つの部品の生産者と消費者のビジネスロジック。ユーザーがあまりにも心配する必要がないので、パフォーマンスのメッセージの場合は、自分自身をキューに入れます。メッセージキューを使用して、企業の大多数のための主な理由は、メッセージキュー自体は、業務システムの処理能力処理能力よりもはるかに大きいです。だから、最高のパフォーマンスを達成するためにメッセージキューのパフォーマンス、メッセージの送受信の両方でより多くの心配、そしてどのように私たちのビジネスコードメッセージキューとを、最適化するため。
1、送信側のパフォーマンスの最適化
メッセージキューにはほとんど、送信側のサービス処理コードのパフォーマンス、そして実際には、送信側は、一般的に最初に独自のビジネスロジックを実行し、最後にメッセージを送信しているため。メッセージ・コードのパフォーマンスが上がることができない送信する場合、メッセージがあまりにも多くの時間がかかり、ビジネスロジックによって引き起こされていない前に、優先度のチェックを与える必要があります。
メッセージを送信するためのビジネスロジックは、唯一の注意を払う必要があり、適切なバッチサイズと複雑を設定するには、我々は、良好な伝送性能を達成することができます。
メッセージを送信するプロデューサ・プロセスは、生産者ブローカは、ブローカへのメッセージは、メッセージを受信した後にアクノリッジ応答を返し、これは完全な双方向性です。この平均遅延時間の相互作用が1msの、我々はアンバンドル入れ1msの時間であると仮定すると、それは以下の時間のかかるこれらのステップを含みます。
- データ送信側は、メッセージの順序論理、および他の構成要求時間、即ち送信要求をネットワーク端末に送信する前に取るを調製します。
- 応答と時間のかかるネットワーク伝送でメッセージを送信することを返します。
- ブローカメッセージ処理遅延。
トランスミッションは、シングルスレッドである場合は、それぞれが1つのメッセージのみ、第二の伝送だけで1000ミリ秒/ 1ミリ秒* 1条/ MS = 1000メッセージを送信し、この場合は、メッセージキューの強さのすべてを再生しません。それはバッチサイズにあなたがメッセージ、または増加の同時実行を送信するたびに増加するかどうかを、指数関数的に送信され、パフォーマンスを向上させることができます。
終わりのように、送信者の業務プログラムの性質に応じて、一括送信または同時増加を選択することです。要するに、限り、あなたはそれを達成することがいかに簡単であるかを実現する方法、性能要件を満たすことができるよう。
- たとえば、あなたの終わりは、マイクロメッセージングサービス、主要な受信者のRPC要求であるオンラインビジネスを処理します。マイクロサービス各要求を扱うときに自然に、それはその上に、現在のスレッドに直接メッセージを送信するすべてのRPCフレームワークであるため、自然にメッセージを送信実現するマルチスレッドサポートマルチ同時並行。そして、オンラインビジネスのケアについての応答遅れを要求することで、選択し一括伝送遅延はRPCサービスに影響を与えるにバインドされています。この場合は、改善するためのより賢明な方法は、同時送信のパフォーマンスを介して行われます。
- お使いのシステムがある場合はオフライン解析システム、オフラインシステム性能の需要が、それは遅延を気にしないということで、システム全体のスループットにもっと注意を払います。データは、このような場合にはより適している、データベース側から送信されるバルク転送、メッセージを送信するために、データベースバルク及びバルクからのデータを読み取ることができ、同じことが並行処理少量の非常に高いスループットを得ることができます。
2、消費者側のパフォーマンスの最適化
メッセージキューを使用する場合、消費者は、メッセージの送信速度の生産終了のスピードを維持することはできません場合は、パフォーマンスの問題のほとんどは、消費者側に浮上している、メッセージがバックログが発生します。消費率は、生産のスピード、長い時間よりも遅くなっている場合、システム全体が問題になります。どちらのメッセージキューストレージサービス、またはメッセージの損失を提供することはできません埋めます。
システムを設計するときに、我々は、生産側のパフォーマンスを送信するよりも、消費者の消費者側のパフォーマンスいることを確認する必要があり、そのシステムは、健康を実行し続けることができます。
消費のビジネスロジックの消費者側を最適化するだけでなく、水平方向の拡大を通じ、消費者の全体的なパフォーマンスを向上させるために、同時最終消費者の数を増やすとパフォーマンスの最適化に加え。注意：拡張消費者と同じ時間のインスタンスの数は、パーティションのトピックが拡大（とも呼ばれるキュー）数を同期させる必要があり、インスタンスの数と数のパーティションの消費者が同じであることを確実にします。消費者のインスタンスの数は、パーティションの数を超えた場合、消費者のために、実際には、唯一の各パーティション上のシングルスレッドの消費をサポートすることができるので、そのような拡張は、実際には何も影響はありません。
多くの消費者プログラムは、彼らが消費の問題を解決することがとても遅いです。
受信したメッセージを処理することサービスロジックは、メッセージバックログ、回避するために、最適化することも困難で遅くなるかもしれないが、メッセージを受信したのonMessage方法を、任意のビジネスロジック、戻りメモリキューにこのメッセージを処理しません。そして、それができる多くの企業のスレッドを起動し、これらのスレッド実際のビジネスロジックの処理ビジネスメッセージがあり、それは、単一の消費者の平行消費の問題を解決することができないように、メッセージ処理スレッドは、メモリキューから取り出しました。
しかし、これはある非常に一般的なエラー方法！なぜ間違っていますか？なぜなら、それはメッセージを失うことになります。ノードがメッセージを受信したダウンした場合、それはメモリキューに失われることはありませんし、これらのメッセージを処理します。