このトピックでは、TCP経由でJavaクライアント用ApsaraMQ for RocketMQ SDKを使用する際のメッセージの蓄積とレイテンシに関するよくある質問に対する回答を提供します。 ApsaraMQ for RocketMQクライアントがメッセージをどのように消費し、メッセージが蓄積される理由を理解したら、ビジネスをデプロイするためのリソースの計画と設定をより適切に行うことができます。 また、O&M中にビジネスロジックをできるだけ早く調整して、メッセージの蓄積やレイテンシによるビジネスオペレーションへの影響を回避することもできます。
背景情報
クライアントのメッセージ消費速度が、メッセージ処理プロセスにおいてブローカのメッセージ送信速度に追いつかないと仮定する。 未処理のメッセージの数は徐々に増加します。 これらのメッセージは、累積メッセージと呼ばれる。 メッセージの蓄積は、メッセージ消費の待ち時間を引き起こす。 次のシナリオでは、メッセージの蓄積と遅延に注意してください。
ビジネスシステムのアップストリーム機能とダウンストリーム機能が互いに一致できないため、メッセージは継続的に蓄積されます。 さらに、メッセージ消費は自動的に回復できません。
ビジネスシステムは、リアルタイムメッセージ消費に対する高い要件を有し、短い蓄積によって引き起こされる待ち時間を受け入れることさえできない。
クライアントはどのようにメッセージを消費しますか?
次の図は、TCPを使用するApsaraMQ for RocketMQ SDKクライアントでの消費プロセスを示しています。
SDKクライアントでプッシュモードでメッセージが消費される場合、消費は次の2つのフェーズで構成されます。
フェーズ1: メッセージをプルします。 SDKクライアントは、長いポーリングメカニズムを使用して、ApsaraMQ for RocketMQブローカーからメッセージをバッチでプルします。 プルされたメッセージは、ローカルバッファキューにキャッシュされます。
高スループットは、ほとんどのイントラネット環境で実装されます。 たとえば、マシンが4コアと8 GBのメモリの仕様を持っているとします。 マシンが単一のスレッドと単一のパーティションを持っている場合、マシンの1秒あたりのトランザクション (TPS) は数万に達する可能性があります。 マシンに複数のパーティションがある場合、TPSは数十万に達する可能性があります。 したがって、このフェーズは、SDKクライアントがバッチでメッセージをプルしても、メッセージの蓄積を引き起こすボトルネックではありません。
フェーズ2: 消費スレッドにメッセージを送信します。 SDKクライアントはローカルにキャッシュされたメッセージを消費スレッドに送信し、スレッドはビジネス消費ロジックを使用してメッセージを処理します。
クライアントの消費能力は、ビジネスロジックの複雑さ (消費時間) と消費の同時実行性に依存します。 ビジネス処理ロジックが複雑で、1つのメッセージを処理するのに時間がかかる場合、全体的なメッセージスループットは高くなりません。 このようにして、クライアントのローカルバッファキューは上限に達し、クライアントはブローカーからのメッセージのプルを停止します。
前述のクライアント側消費メカニズムに基づくと、メッセージ蓄積を引き起こす主なボトルネックは、ローカルクライアントの消費能力にある。 これは、消費時間と消費同時実行がメッセージを蓄積するかどうかを決定することを意味します。 メッセージ蓄積の問題を回避または解決するには、消費時間と同時実行を適切に制御する必要があります。 消費時間は、消費同時実行よりも優先されます。 したがって、消費時間が合理的であることを前提に、適切な消費同時実行を設定します。
消費時間
消費時間に影響を与える消費ロジックには、CPUとインメモリコンピューティングおよび外部I/O操作が含まれます。 外部I/O操作と比較して、複雑な再帰とループがコードで定義されていない場合、内部計算時間はほとんど無視できます。 外部I/O操作には通常、次のビジネスロジックが含まれます。
MySQLデータベースなどの外部データベースでのデータの読み取りと書き込み。
Redisなどの外部キャッシュシステムでのデータの読み取りと書き込み。
Dubbo呼び出しや下流HTTPインターフェイス呼び出しなどの下流システム呼び出し。
このような外部呼び出しのロジックとシステム容量を整理して、各呼び出しで消費される予想時間を理解する必要があります。 このようにして、消費ロジックのI/O操作で消費される時間が妥当かどうかを判断できます。 ほとんどの場合、メッセージは、サービスの例外または下流システムの容量制限のために消費時間が増加するために蓄積されます。
データをデータベースに書き込む必要があり、ビジネスの消費ロジックでは、1つのメッセージの消費時間が1ミリ秒であると仮定します。 メッセージの量が少ないため、ほとんどの場合エラーは発生しません。 ビジネス側が大規模なプロモーションを行うと、データベースに対する書き込み操作のTPSが爆発し、データベース容量の限界に達します。 その結果、単一のメッセージを消費する時間は100ミリ秒に増加する。 消費速度は急激に低下した。 この問題は、ApsaraMQ for RocketMQ SDKクライアントの消費同時実行性を調整するだけでは解決できません。 クライアントの消費能力を根本的に改善するには、データベース容量をアップグレードする必要があります。
消費並行性
次の表に、ApsaraMQ for RocketMQでメッセージ消費の同時実行性を計算する方法を示します。
メッセージタイプ | 消費の同時実行 |
通常のメッセージ | ノードあたりのスレッド数 × ノード数 |
スケジュールされたメッセージと遅延メッセージ | |
トランザクションメッセージ | |
注文メッセージ | Min (ノードあたりのスレッド数 × ノード数, パーティション数) |
クライアントの消費同時性は、ノードごとのスレッド数とノード数によって決まります。 ほとんどの場合、最初に単一ノードのスレッド数を調整する必要があります。 単一ノードのハードウェアリソースが上限に達している場合は、ノードを追加して消費の同時実行性を高める必要があります。
順序付けられたメッセージの消費同時性は、トピック内のパーティションの数によっても制限されます。 Alibaba Cloud Customer Servicesに連絡して、パーティションの数を評価してください。
1つのノードで消費の同時実行性を慎重に設定します。 スレッドの数が多すぎると、スレッド切り替えのオーバーヘッドが大きくなります。 次のモデルを使用して、理想的な環境で1つのノードに最適なスレッド数を計算します。
1つのノードのvCPUの数はCです。
スレッドの切り替えにかかる時間は無視され、I/O操作はCPUリソースを消費しません。
スレッドには処理を待つ十分なメッセージがあり、メモリは十分です。
論理では、CPU時間はT1であり、外部I/O動作時間はT2である。
したがって、単一のスレッドは、1/(T1 + T2) のTPSを達成することができる。 CPU使用率が目的の値100% に達した場合、C × (T1 + T2)/T1スレッドを設定して、単一ノードが最大消費能力に達するようにする必要があります。
この例のスレッドの最大数は、理想的な環境下で得られた理論的なデータのみです。 実際のアプリケーション環境では、スレッド数を徐々に増やし、効果を観察してから調整することをお勧めします。
メッセージの蓄積と遅延を回避するにはどうすればよいですか?
予期しないメッセージの蓄積と遅延を回避するには、設計の初期段階でビジネスロジック全体を確認して整理する必要があります。 障害が発生したときにブロッキングポイントを特定できるように、通常のビジネス操作のパフォーマンスベースラインを整理できます。 主なタスクは、メッセージの消費時間と並行性を整理することです。
メッセージの消費時間を並べ替える
ストレステストを実行してメッセージの消費時間を取得し、時間のかかる操作のコードロジックを分析します。 消費時間のクエリ方法の詳細については、「メッセージの消費時間のクエリ」をご参照ください。 メッセージの消費時間を整理するときは、次の情報に注意してください。
メッセージ消費ロジックの計算の複雑さが高すぎるかどうか、およびコードに無限ループや再帰などの欠陥があるかどうかを確認します。
メッセージ消費ロジックで、外部呼び出しや読み取り /書き込みストレージなどのI/O操作が必要かどうかを確認します。 さらに、ローカルキャッシュなどのソリューションを使用してこれらの操作を回避できるかどうかを確認します。
消費ロジックの複雑で時間のかかる操作を非同期で処理できるかどうかを確認します。 操作を非同期で処理できる場合は、非同期操作によってロジックが混乱するかどうかを確認します。 例えば、消費は完了しているが、非同期動作は完了していない。
メッセージ消費の同時実行性を設定する
1つのノードのスレッド数を徐々に増やします。 次に、ノードのメトリックを観察して、ノードの最適な消費スレッド数と最大メッセージスループットを取得できます。
1つのノードに最適なスレッド数とメッセージスループットを取得したら、必要なノード数を計算します。 ノード数=単一スレッドのピークトラフィック /メッセージスループットを使用して、アップストリームリンクとダウンストリームリンクのピークトラフィックに基づいて計算できます。
メッセージの累積と遅延を解決するにはどうすればよいですか?
メッセージの蓄積や待ち時間がビジネスに与える影響を回避するために、ApsaraMQ for RocketMQが提供するモニタリングおよびアラート機能を使用してアラートルールを設定できます。 このようにして、システムはメッセージの蓄積に関するアラートを送信します。 イベント追跡を使用して、メッセージの蓄積を監視し、問題が発生した直後に処理することもできます。 アラートルールの設定方法の詳細については、「モニタリングとアラート」をご参照ください。
ビジネスニーズに基づいて、メッセージ蓄積のアラートルールのしきい値を設定します。 閾値が低すぎる場合、アラートは頻繁にトリガされ得る。 しきい値が高すぎると、アラートを受信してトラブルシューティングを行うことができません。
メッセージ蓄積アラートの処理方法の詳細については、蓄積されたメッセージをどのように処理できますか?