ApsaraMQ for RocketMQ インスタンスでメッセージ蓄積アラートがトリガーされると、リアルタイム蓄積メッセージ数 の値が グループ詳細 ページで想定より高くなります。また、メッセージトレース ページでは、メッセージがブローカーに公開されているものの、コンシューマーへの配信が完了していない状態として表示されます。
以下の手順に従って、蓄積の根本原因を特定し、問題を解決してください。
メッセージが蓄積する理由
メッセージがブローカーに送信された後、コンシューマークライアントはコンシューマオフセットに基づいてメッセージをプルします。蓄積は、クライアントがメッセージを十分な速度で消費できない場合に発生します。主な原因は以下の 2 つです：
消費時間の長さ — 消費スレッド内のビジネスロジックが、1 件のメッセージあたり過度に長い時間を要しています。
スレッド同時実行数の不足 — 受信メッセージのレートに対応できるだけの消費スレッド数が確保されていません。
詳細については、「メッセージ蓄積とレイテンシ」をご参照ください。
トラブルシューティング
ステップ 1：メッセージ蓄積の発生場所を特定
クライアントの ons.log ファイルを確認し、以下のログメッセージを探します：
the cached message count exceeds the thresholdログメッセージが検出された場合 — クライアント側バッファーキューが満杯です。メッセージはクライアント側で蓄積しています。ステップ 2 に進んでください。
ログメッセージが検出されなかった場合 — メッセージはクライアント側で蓄積していません。お問い合わせは Alibaba Cloud テクニカルサポート までご連絡ください。
ステップ 2：メッセージ消費時間の確認
1 件のメッセージあたりの消費時間が異常に長い場合は、根本原因はビジネスロジックにある可能性が高いです。ステップ 3 に進み、スレッドスタックを確認してください。
消費時間が正常な場合は、スレッド同時実行数の不足が蓄積の原因です。以下の対応を行ってください：
消費スレッド数を増加させます。
コンシューマーノードを追加してスケールアウトします。
消費時間の確認方法
以下のいずれかの方法をご利用ください：
メッセージトレース — ApsaraMQ for RocketMQ コンソール にログインし、メッセージトレース ページを開き、クエリタスクの作成 をクリックします。メッセージ ID によるクエリ を選択して該当メッセージを特定し、コンシューマー セクションの 消費時間 の値を確認します。詳細については、「メッセージトレースのクエリ」をご参照ください。
グループ詳細 — グループ詳細 ページで クライアント接続情報 セクションを確認し、対象クライアントの 操作 列から 詳細表示 をクリックします。応答時間 (ms/メッセージ) フィールドに、1 件のメッセージあたりの平均消費時間が表示されます。詳細については、「コンシューマー詳細の表示」をご参照ください。
モニタリングサービス — Application Real-Time Monitoring Service (ARMS) またはその他のモニタリングソリューションを用いて、消費時間のメトリックを収集します。
ステップ 3：ConsumeMessageThread スタックの確認
ConsumeMessageThread スレッドにはメッセージ消費ロジックが含まれており、そのスタックを確認することで、ブロッキング呼び出し、過剰なスリープ、外部 I/O の遅延など、ボトルネックを特定できます。
スレッド状態の解釈方法については、Java Thread.State ドキュメント をご参照ください。
スレッドスタックの取得方法
オプション A：ApsaraMQ for RocketMQ コンソール
グループ詳細 ページで クライアント接続 セクションを確認し、対象クライアントの 操作 列から スタック情報の表示 をクリックします。詳細については、「コンシューマー詳細の表示」をご参照ください。
オプション B：ホストでの jstack 実行
蓄積メッセージを持つコンシューマーインスタンスが実行されているホストにログインします。ホスト IP の確認方法については、「コンシューマーのステータスの表示」をご参照ください。
Java プロセス ID を特定します：
ps -ef | grep java jps -lmスレッドスタックをダンプします：
jstack -l <pid> > /tmp/<pid>.jstackConsumeMessageThreadのエントリをフィルタリングします：cat /tmp/<pid>.jstack | grep ConsumeMessageThread -A 10 --color
代表的なスタックパターン
アイドルスレッド（蓄積なし）
消費スレッドは WAITING 状態であり、クライアント側バッファーキューからメッセージをプルするのを待機しています。これは、消費対象のメッセージがない場合の正常な動作です。
スリープまたはロック競合によるスレッドブロッキング
消費スレッドが sleep() 呼び出しでブロックされており、消費が遅延しています。
外部 I/O によるスレッドブロッキング
消費スレッドが外部 HTTP 呼び出しやデータベース操作でブロックされており、消費が遅延しています。
ステップ 4：蓄積メッセージのスキップ（任意）
蓄積したメッセージがもはや関連性を失っており、安全にスキップ可能である場合、コンシューマオフセットを最新位置にリセットします。これにより、コンシューマーは最新のメッセージから消費を開始し、蓄積分をスキップします。
手順については、「コンシューマオフセットのリセット」をご参照ください。
コンシューマオフセットをリセットすると、すべての蓄積メッセージがスキップされます。実行前に、これらのメッセージが今後不要であることを必ず確認してください。
次のステップ
メッセージ蓄積とレイテンシ — 消費メカニズムおよび蓄積の根本原因について説明します。
コンシューマー詳細の表示 — コンシューマーのステータス、接続情報、およびスタックトレースを確認できます。
コンシューマオフセットのリセット — 最大オフセットへリセットすることで、蓄積メッセージをスキップできます。