Kafkaトピックとパーティションについて
エンタープライズソリューションの目的でKafkaを学び始めています。
読書中に、いくつかの質問が思い浮かびました。
- プロデューサーがメッセージを作成するとき-メッセージを送信するtopicを指定しますが、そうですか？パーティションを気にしますか？
- サブスクライバーが実行されている場合、同じトピックのコンシューマーのクラスターまたはこのコンシューマーのグループが関心を持っているいくつかのトピックの一部になることができるように、グループIDを指定しますか？
各消費者グループにはブローカーに対応するパーティションがありますか、それとも各消費者にパーティションがありますか？
パーティションはブローカーによって作成されたので、消費者の懸念ではありませんか？
これは各パーティションのオフセットを持つキューであるため、読み取るメッセージを指定するのはコンシューマーの責任ですか？状態を保存する必要がありますか？
メッセージがキューから削除されるとどうなりますか？ -たとえば、保持が3時間で、時間が経過すると、両側でオフセットはどのように処理されますか？
この投稿には既に回答がありますが、Kafka Definitive Guideの写真をいくつか追加してビューを追加しています
各質問に答える前に、生産者コンポーネントの概要を追加しましょう：
1.プロデューサーがメッセージを作成しているとき-メッセージの送信先のトピックを指定します、そうですか？パーティションを気にしますか？
プロデューサーは、以下に応じて、メッセージを配置するターゲットパーティションを決定します。
- パーティションID（メッセージ内で指定されている場合）
- key％num partitions、パーティションIDが記載されていない場合
- partition idもmessage keyもメッセージで利用できない場合、ラウンドロビン、値のみが利用可能であることを意味します
2.サブスクライバーが実行されている場合-同じトピックのコンシューマーのクラスターまたはこのコンシューマーのグループが関心を持っているいくつかのトピックの一部になることができるように、グループIDを指定しますか？
単純な割り当てAPIを使用しており、Kafkaにオフセットを保存する必要がない場合を除き、常にgroup.idを構成する必要があります。グループの一部にはなりません。 ソース
3.各コンシューマグループにはブローカーに対応するパーティションがありますか、または各コンシューマにパーティションがありますか？
1つのコンシューマグループでは、各パーティションは1つのコンシューマのみによって処理されます。これらは可能なシナリオです
- コンシューマーの数はより少ないトピックパーティションの数であり、グループ内のコンシューマーの1つに複数のパーティションを割り当てることができます
![number of consumers less than topic partitions]()
- コンシューマーの数トピックパーティションの数と同じ、パーティションとコンシューマーマッピングは以下のようになります。
![number of consumers same as number of topic partitions]()
- コンシューマの数はトピックパーティションの数より大きいため、パーティションとコンシューマのマッピングは以下のようになりますコンシューマーを確認5
![number of consumers more than number of topic partitions]()
4.ブローカーによって作成されたパーティションとして、したがって、消費者の懸念はありませんか？
質問3で説明したように、消費者はパーティションの数に注意する必要があります。
5.これは各パーティションのオフセットを持つキューであるため、読みたいメッセージを指定するのは消費者の責任ですか？状態を保存する必要がありますか？
Kafka（具体的にはGroup Coordinator）は、内部__ consumer_offsetsトピック、enable.auto.commitをfalseに設定することにより、この動作を手動で構成することもできます。その場合、consumer.commitSync()とconsumer.commitAsync()はオフセットの管理に役立ちます。
Group Coordinatorの詳細：
- Kafkaサーバー側からクラスター内で選択されたブローカーの1つです。
- コンシューマはGroup Coordinatorと対話して、オフセットコミットとフェッチリクエストを行います。
- コンシューマは定期的なハートビートをGroup Coordinatorに送信します。
6.メッセージがキューから削除されるとどうなりますか？ -たとえば：保持は3時間でしたが、時間が経過すると、両側でどのようにオフセットが処理されますか？
保持期間後にコンシューマーが起動した場合、メッセージはauto.offset.resetの構成に従ってlatest/earliest構成に従ってコンシュームされます。技術的にはlatest（新しいメッセージの処理を開始）です。その時間までにすべてのメッセージが期限切れになり、retentionはトピックレベルの構成です。
それらを順番に見てみましょう:)
1-プロデューサーがメッセージを作成している場合-メッセージの送信先のトピックを指定します、そうですか？パーティションを気にしますか？
デフォルトでは、プロデューサーはパーティション化を気にしません。カスタマイズされたパーティショナーを使用してより良い制御を行うオプションがありますが、完全にオプションです。
2-サブスクライバーが実行されている場合-同じトピックのコンシューマーのクラスターまたはこのコンシューマーのグループが関心を持っているいくつかのトピックの一部になることができるように、グループIDを指定しますか？
はい、消費者は、負荷を共有するために消費者グループに参加します（または、単独の場合は作成します）。同じグループの2人の消費者が同じメッセージを受け取ることはありません。
3-各消費者グループにはブローカーに対応するパーティションがありますか、それとも各消費者にパーティションがありますか？
どちらでもない。消費者グループのすべての消費者には、2つの条件でパーティションのセットが割り当てられます。同じグループの2つの消費者に共通のパーティションはありません。また、消費者グループ全体に既存のパーティションが割り当てられます。
4-パーティションはブローカーによって作成されたので、消費者の懸念ではありませんか？
そうではありませんが、既存のパーティションよりも多くのコンシューマーを持つことはまったく役に立たないことが3からわかるので、消費するための最大並列処理レベルです。
5-これは各パーティションのオフセットを持つキューであるため、読みたいメッセージを指定するのは消費者の責任ですか？状態を保存する必要がありますか？
はい、消費者はパーティションごとにトピックごとにオフセットを保存します。これはカフカによって完全に処理され、心配する必要はありません。
6-メッセージがキューから削除されるとどうなりますか？ -たとえば：保持は3時間でしたが、時間が経過すると、両側でどのようにオフセットが処理されますか？
消費者がブローカーのパーティションで使用できないオフセットを要求した場合（たとえば、削除のため）、エラーモードになり、最終的にこのパーティションで使用可能な最新または最も古いメッセージにリセットされます（ auto.offset.reset構成値）、および作業を続行します。
KafkaはTopic概念を使用して、メッセージフローに順序を付けます。
負荷を分散するために、トピックを複数のパーティションに分割し、ブローカー間で複製できます。
パーティションは順序付けられた不変のメッセージのシーケンスであり、継続的に追加されます。つまり、コミットログです。
パーティション内のメッセージには、パーティション内の各メッセージを一意に識別する連続したID番号があります。
パーティションを使用すると、単一のサーバー（ブローカー）に収まるサイズを超えてトピックのログを拡張でき、並列処理の単位として機能します。
トピックのパーティションは、Kafkaクラスター内のブローカーに分散されます。各クラスターでは、パーティションの共有に対するデータとリクエストを処理します。
各パーティションは、構成可能な数のブローカーに複製され、フォールトトレランスを保証します。
この記事でよく説明されています： http://codeflex.co/what-is-Apache-kafka/