Kafkaのトピックとパーティションについて

エンタープライズソリューションの目的でKafkaを学び始めています。

私の読書中に、いくつかの質問が私の頭に浮かびました：

1. プロデューサーがメッセージを生成しているとき-メッセージを送信したいトピックを指定します、そうですか？パーティションを気にしますか？
2. サブスクライバーが実行中の場合、サブスクライバーはグループIDを指定して、同じトピックのコンシューマーのクラスターの一部になることができますか？

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

4. パーティションはブローカーによって作成されているので、コンシューマーには関係ありませんか？

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

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

この投稿にはすでに回答がありますが、Kafka Definitive Guideの写真をいくつか追加して、ビューを追加しています

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

1.プロデューサーがメッセージを生成しているとき-メッセージを送信するトピックを指定しますが、そうですか？パーティションを気にしますか？

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

• メッセージ内で指定されている場合、パーティションID
• キー％numパーティション（パーティションIDが指定されていない場合）
• メッセージでパーティションIDもメッセージキーも使用できない場合のラウンドロビン。値のみが使用可能であることを意味します

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

単純な割り当てAPIを使用していて、Kafkaにオフセットを保存する必要がない限り、常にgroup.idを構成する必要があります。グループの一部にはなりません。ソース

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

1つのコンシューマグループでは、各パーティションは1つのコンシューマのみによって処理されます。これらは可能なシナリオです

• コンシューマの数がトピックパーティションの数より少ない場合、グループ内のコンシューマの1つに複数のパーティションを割り当てることができます
• トピックパーティションの数と同じコンシューマーの数。パーティションとコンシューマーのマッピングは以下のようになります。
• コンシューマーの数がトピックパーティションの数よりも多い場合、パーティションとコンシューマーのマッピングは次のようになります。効果がありません。コンシューマー5を確認してください

4.ブローカーによって作成されたパーティションとして、したがって、コンシューマーにとって心配ではありませんか？

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

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

Kafka（特定のグループコーディネーターになる）は、内部の__consumer_offsetsトピックにメッセージを生成することでオフセット状態を処理します。この動作は、に設定することで手動にも設定enable.auto.commitできfalseます。その場合consumer.commitSync()、consumer.commitAsync()オフセットの管理に役立ちます。

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

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

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

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

それらを順番に見ていきましょう:)

1-プロデューサーがメッセージを生成しているとき-メッセージを送信するトピックを指定しますが、そうですか？パーティションを気にしますか？

デフォルトでは、プロデューサーはパーティション化を気にしません。カスタマイズされたパーティショナーを使用してより適切に制御するオプションがありますが、それは完全にオプションです。

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

はい。コンシューマは、コンシューマグループに参加して（または自分だけの場合は作成して）負荷を共有します。同じグループの2つのコンシューマーが同じメッセージを受信することはありません。

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

どちらでもない。コンシューマグループ内のすべてのコンシューマには、一連のパーティションが割り当てられます。2つの条件：同じグループ内の2つのコンシューマに共通のパーティションがないこと、およびコンシューマグループ全体として、既存のすべてのパーティションが割り当てられます。

4-パーティションはブローカーによって作成されているので、コンシューマーには関係ありませんか？

そうではありませんが、3からわかるように、既存のパーティションよりも多くのコンシューマーを持つことはまったく役に立たないので、消費するための最大並列レベルです。

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

はい、コンシューマはパーティションごとのトピックごとのオフセットを保存します。これは完全にKafkaによって処理され、心配する必要はありません。

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

コンシューマーがブローカーのパーティションで使用できないオフセットを要求した場合（たとえば、削除のため）、エラーモードに入り、最終的にこのパーティションに対して、使用可能な最新または最も古いメッセージのいずれかにリセットされます。 auto.offset.reset構成値）、作業を続行します。

Kafkaはトピックを使用して、メッセージフローに秩序をもたらします。

負荷を分散するために、トピックは複数のパーティションに分割され、ブローカー間で複製されます。

パーティションは、順序付けされた不変のメッセージシーケンスであり、継続的に追加されます（つまり、コミットログ）。

パーティション内のメッセージには、パーティション内の各メッセージを一意に識別する連続ID番号があります。

パーティションを使用すると、トピックのログを単一のサーバー（ブローカー）に収まるサイズを超えてスケ​​ーリングし、並列処理の単位として機能させることができます。

トピックのパーティションは、各ブローカーがデータの処理とパーティションの共有の要求を処理するKafkaクラスターのブローカーに分散されます。

各パーティションは、フォールトトレランスを確保するために、構成可能な数のブローカー間で複製されます。

この記事でよく説明されています：http : //codeflex.co/what-is-apache-kafka/