問題の現象
データ購読のシナリオでは、ユーザーが自身の消費プログラムを使用してデータを消費する際に、以下のような異常が発生する可能性があります。
1. データを消費できません。
2. 消費したデータが失われるか、重複することがあります。
3. コンシューマー側の遅延がますます大きくなっています。
調査方針
1. データを消費できない
ユーザーが自身のコンシューマープログラムでデータを消費できない場合は、まずDTSが提供するDemoを使用して消費テストを行ってください。
DTSが提供するDemoを使用してデータを消費できる場合は、ユーザー自身の消費プログラムを確認する必要があります。
DTSが提供するDemoを使用してもデータを消費できない場合は、以下のように確認する必要があります：
コンシューマー側のネットワーク環境が要件を満たしているかどうかをチェックしてください。コンシューマー側はTencent Cloudのプライベートネットワーク内にあり、かつDTS購読タスクと同じ地域にある必要があります。
Demoを起動するためのパラメータ入力に誤りがないか、特にコンシューマグループのパスワードをチェックしてください。
Demoのバージョンが正しく使用されているかをチェックしてください。ソースデータベースのタイプやデータ形式が異なる場合は、異なるDemoバージョンを使用する必要があります。
購読タスクにデータがKafkaに書き込まれているかどうかをチェックしてください（コンソールのコンシューマグループ管理で、未消費のメッセージ数がゼロより大きいかどうかを確認してください）。
2. 消費したデータの欠落または重複
一部の購読タスクが再起動されるいくつかのシナリオでは、プロデューサー側でデータ重複が発生する可能性があり、その結果、消費されたデータにも重複が発生します。ただし、これは少数のケースに該当し、これ以外に発生するその他のデータ重複やデータ損失は想定外です。 ユーザーが消費したデータが想定と異なり、データの重複や欠落などの問題が発生する場合、一般的な原因はユーザーの消費プログラムの処理異常です。まず問題を再現してください。具体的な問題再現の操作は、以下のいずれかを参照してください：
コンソール上でKafkaのオフセットを調整し、オフセットを以前の位置に戻して再度消費します。
新しいコンシューマグループを作成し、その新しいコンシューマグループで重複して消費します。（異なるコンシューマグループでの消費は互いに影響しません）
問題を再現できる場合は、チケットを提出して処理します。再現できない場合は、ユーザーの消費プログラムに問題がある可能性がありますので、まず消費プログラムをチェックしてください。 3. コンシューマー側のデータ遅延が増大する
1. コンシューマープログラムのcommitロジックの問題。
もし消費プログラムが消費のみを行いcommitを行わない場合、Kafkaのオフセットは更新されません。DTS Demoにおけるデフォルトのcommitロジックは以下の通りです：checkpointタイプのメッセージを消費したときに一度commitを行います。購読サービスは約10秒ごとにcheckpointタイプのメッセージを1つ書き込みます。ユーザーがcommitルールを変更した場合、この問題が発生する可能性があります。まず消費プログラム内のcommitルールを確認してください。
2. 消費効率が低すぎます。
消費効率は、ネットワーク状況、消費プログラムの処理効率、並行消費、マルチパーティション消費など、複数の要因の影響を受けます。ユーザーは新しいコンシューマグループを作成し、DTSが提供するDemoで消費して、ユーザー自身の消費プログラムの速度と比較し、消費プログラムの効率上のボトルネックを切り分けることができます。その他については、ユーザーがネットワーク状況をチェックし、データ処理速度を向上させるか、コンシューマー数を増やす必要があります。複数パーティションのtopicでは、できるだけマルチプロセスによる並行消費を使用してください。