Kafkaのトピックとパーティションを理解する 質問する

この投稿にはすでに回答がありますが、私はKafka Definitive Guideからいくつかの写真とともに私の見解を追加します。

質問に答える前に、プロデューサー コンポーネントの概要を見てみましょう。

1. プロデューサーがメッセージを生成するとき、そのメッセージを送信するトピックを指定します。これは正しいですか? パーティションは考慮されますか?

プロデューサーは、次の要素に応じて、メッセージを配置するターゲット パーティションを決定します。

• メッセージ内で指定されている場合のパーティションID
• キー % パーティション数、パーティションIDが指定されていない場合
• ラウンドロビンでは、メッセージにパーティションIDもメッセージキーもない場合は、値のみが使用可能になります。

2. サブスクライバーが実行中の場合 - サブスクライバーは、同じトピックのコンシューマーのクラスターの一部となるように、またはこのコンシューマー グループが関心を持つ複数のトピックの一部となるように、グループ ID を指定しますか?

シンプルな割り当て API を使用していて、Kafka にオフセットを保存する必要がない場合を除き、常にgroup.idを構成する必要があります。これはどのグループにも属しません。ソース。

3. 各コンシューマー グループにはブローカー上に対応するパーティションがありますか、それとも各コンシューマーに 1 つずつありますか?

1つのコンシューマグループでは、各パーティションは1つのコンシューマによってのみ処理されます。考えられるシナリオは次のとおりです。

• コンシューマーの数がトピックパーティションの数より少ない場合、グループ内のコンシューマーの1つに複数のパーティションを割り当てることができます。

  

• コンシューマーの数がトピックパーティションの数と同じ場合、パーティションとコンシューマーのマッピングは次のようになります。

  

• コンシューマーの数がトピックパーティションの数より多い場合、パーティションとコンシューマーのマッピングは以下のようになります。有効ではありません。コンシューマー5を確認してください。

  

4. パーティションはブローカーによって作成されるため、消費者にとって問題ではないのでしょうか?

質問 3 で説明したように、消費者はパーティションの数に注意する必要があります。

5. これは各パーティションのオフセットを持つキューなので、どのメッセージを読み取るかを指定するのはコンシューマーの責任ですか? 状態を保存する必要がありますか?

Kafka (具体的にはGroup Coordinator ) は、内部の__consumer_offsetsトピックにメッセージを生成することでオフセット状態を処理します。この動作は、enable.auto.commitに設定することで手動でも構成できますfalse。その場合consumer.commitSync()、 と はconsumer.commitAsync()オフセットの管理に役立ちます。

グループコーディネーターの詳細:

1. これは、Kafka サーバー側からクラスター内で選択されたブローカーの 1 つです。
2. コンシューマーは、オフセット コミットとフェッチ要求についてグループ コーディネーターと対話します。
3. コンシューマーはグループ コーディネーターに定期的にハートビートを送信します。

6. メッセージがキューから削除されるとどうなりますか? - たとえば、保持期間が 3 時間で、その後時間が経過した場合、両側でオフセットはどのように処理されますか?

auto.offset.reset保持期間後にコンシューマーが開始した場合、メッセージは構成に従って消費されますlatest/earliest。技術的には、latestすべてのメッセージがその時間までに期限切れになり、保持がトピック レベルの構成であるため、(新しいメッセージの処理を開始) になります。