クライアントがサーバーに初めて接続する際の接続失敗のトラブルシューティング方法
以下の設定が正しいことを確認してください。
エンドポイントが正しく指定されていることを確認してください。エンドポイントは、ApsaraMQ for RocketMQ コンソールの インスタンスの詳細 ページで取得できます。
telnet <エンドポイントのドメイン名> <ポート番号>コマンドを実行して、ネットワーク接続性を確認してください。アプリケーションがオンプレミスにデプロイされている場合、またはリージョン間アクセスが必要で Cloud Enterprise Network (CEN) を使用してネットワークを構築できない場合は、パブリックエンドポイントを使用して ApsaraMQ for RocketMQ インスタンスにアクセスします。 パブリックエンドポイントを使用すると、アウトバウンドトラフィック料金が発生します。 詳細については、「4.x シリーズインスタンスのパブリックネットワークアクセス料金または5.x シリーズインスタンスのパブリックネットワークアクセス料金」をご参照ください。
アプリケーションが Alibaba Cloud Elastic Compute Service (ECS) インスタンスにデプロイされている場合は、VPC エンドポイントを使用して、仮想プライベートクラウド (VPC) 経由でApsaraMQ for RocketMQ インスタンスにアクセスします。このシナリオでは、ECS インスタンスがApsaraMQ for RocketMQ インスタンスと同じリージョンにある必要があります。
パブリックネットワークアクセスが有効になっている 5.0 シリーズのインスタンスでは、ホワイトリストが設定されているかどうかを確認します。デフォルトでは、パブリックネットワークアクセスはすべての IP アドレスからの接続を許可します。ホワイトリストが設定されている場合、ホワイトリスト内の IP アドレスのみが ApsaraMQ for RocketMQ にアクセスできます。
トピック名が正しいことを確認してください。名前に余分なスペースや特殊文字が含まれていないこと、およびトピックがコンソールで作成されていることを確認してください。
ユーザー名とパスワードが正しいことを確認してください。
5.0 シリーズのインスタンスの場合、インスタンスのユーザー名とパスワードを入力します。これらはコンソールのインスタンス詳細ページから取得できます。
4.0 シリーズのインスタンスの場合、Alibaba Cloud アカウントまたは Resource Access Management (RAM) ユーザーの AccessKey ID と AccessKey シークレットを入力します。ユーザーに必要な権限が付与されていることを確認してください。AccessKey ペアを取得するには、「AccessKey ペアの作成」をご参照ください。
サブスクリプション関係に不整合がある場合の対処法
コンソールにログインし、グループ ページに移動して、指定したグループのサブスクリプション関係とコンシューマー情報を表示してください。サブスクリプション関係に不整合があるコンシューマーのサブスクリプションコードを変更し、一貫性を確保してください。
詳細なトラブルシューティング手順については、「ApsaraMQ for RocketMQ におけるサブスクリプション関係の不整合のトラブルシューティング方法」をご参照ください。
メッセージの滞留の対処法
メッセージの滞留は、以下の理由で発生する可能性があります。
コンシューマーのメッセージ処理ロジックが異常で、メッセージを消費できません。
メッセージプロデューサーアプリケーションでトラフィックバーストが発生します。メッセージの生成レートが消費レートを大幅に上回り、メッセージの滞留が発生します。
コンシューマーが依存するダウンストリームサービスのレスポンスタイムが増加し、消費スレッドがブロックされます。
消費スレッドの数が不足しています。コンシューマーの同時実行性が低いため、消費レートが生成レートに追いつきません。
クライアントログまたはスタック情報を確認して、例外の原因を特定してください。詳細については、「メッセージの滞留の処理方法」をご参照ください。
コンシューマーがメッセージを消費できない場合の対処法
ApsaraMQ for RocketMQコンソールにログインし、グループ ページに移動して、コンシューマーがオンラインであり、クライアント接続が正常であることを確認してください。クライアントが接続されていない場合は、クライアントログを確認してエラーを特定し、修正してください。
サブスクリプション関係に一貫性があることを確認してください。一貫性がない場合は、サブスクリプション関係の詳細に基づいてコンシューマークライアントを特定し、クライアントのメッセージサブスクリプションコードを変更してください。
コンシューマーグループ内のマシンがダウンした場合、再起動中にメッセージは失われますか？
いいえ、そうではありません。ApsaraMQ for RocketMQ は永続サブスクリプションを使用します。コンシューマーグループがオフラインになったり、消費例外が発生したりしても、メッセージが失われることはありません。コンシューマークライアントがオンラインに戻ると、中断したオフセットから消費を再開します。
メッセージをサブスクライブする際にメッセージタグを空にできますか？
いいえ。メッセージをサブスクライブする際に空のタグを設定すると、コンシューマーはメッセージを受信しません。トピック内のすべてのメッセージをサブスクライブするには、タグを * に設定してください。次のサンプルコードに例を示します。
String topic = "Your Topic";
// タグを使用してメッセージをフィルタリングします。これはすべてのメッセージをサブスクライブします。
FilterExpression filterExpression = new FilterExpression("*", FilterExpressionType.TAG);
pushConsumer.subscribe(topic, filterExpression);詳細については、「タグベースのフィルタリング」をご参照ください。
新しいコンシューマーグループを作成して既存のトピックをサブスクライブする際の、初回コンシューマーオフセットの設定方法
コンシューマーグループの作成時に、初回のコンシューマーオフセットを設定することはできません。デフォルトでは、コンシューマーが初めて起動すると、新しいトピックをサブスクライブしているか、既存のトピックをサブスクライブしているかに関わらず、トピック内の最も古いメッセージから消費を開始します。
コンシューマーが初めて起動した後、ApsaraMQ for RocketMQ コンソールでコンシューマーオフセットをリセットできます。詳細については、「コンシューマーオフセットのリセット」をご参照ください。
オンラインのコンシューマーがメッセージを消費せず、グループでメッセージが滞留している場合の対処法
コンシューマーグループがトピックに使用するサブスクリプション方式を確認してください。コンシューマーがメッセージフィルタリングを使用してトピックをサブスクライブしている場合、フィルター条件に一致しないメッセージは滞留としてカウントされます。これは想定された動作です。詳細については、「メッセージフィルタリング」をご参照ください。
SQL フィルタリングまたはタグベースのフィルタリングを使用していて、メッセージが消費されていないにもかかわらずグループでメッセージが滞留している場合、滞留メッセージ数は次のように計算されます。
SQL フィルタリング：滞留メッセージ数 = 準備完了メッセージ数 + Inflight メッセージ数 - フィルタリング条件を満たさないメッセージ数
タグベースのフィルタリング：滞留メッセージ数 = (準備完了メッセージ数 + Inflight メッセージ数) × タグに一致するメッセージの割合
タグに一致するメッセージの割合 = サンプル内でタグに一致するメッセージ数 / サンプリングされたメッセージの総数
ダッシュボードに大量のメッセージの滞留が表示されているが、コンシューマー側ではメッセージがすでに消費済みである場合の対処法
この問題は、Remoting プロトコルソフトウェア開発キット (SDK) を使用し、コンシューマーで消費モードをブロードキャスト消費に設定している場合に発生する可能性があります。サーバー側はコンシューマーオフセット情報に基づいてメッセージの滞留を判断します。しかし、ブロードキャスト消費モードでは、コンシューマーオフセットはクライアント側で維持されます。その結果、ダッシュボードにメッセージの滞留が誤って表示されることがあります。
さらに、コンシューマーがタグベースのフィルタリングまたは SQL フィルタリングを使用している場合、フィルター条件に一致しないメッセージは滞留していると見なされます。
順序付きメッセージの消費におけるリトライ詳細の表示方法
順序付きメッセージの消費のリトライは、コンシューマークライアント上でローカルに実行されます。したがって、サーバー側のメッセージトレースから特定のリトライ情報を照会することはできません。
クライアントログから詳細なリトライ情報を照会できます。以下のログキーワードを使用できます。
RocketMQ Remoting SDK：
consumeMessage exception: {} Group: {} Msgs: {} MQ: {}consumeMessage Orderly return not OK, Group: {} Msgs: {} MQ: {}
RocketMQ gRPC SDK：
Prepare to redeliver the fifo message because of the consumption failure, maxAttempt={}, attempt={}, mq={}, messageId={}, nextAttemptDelay={}, clientId={}