関連する記録とカフカのメッセージの下で、ファイル、インデックスファイル、消費者オフセット記録に関連するコンテンツの消費を記録し、テキストの理解の多くは、テキストボーエン、書籍だけでなく、高齢者の最後を参照してください。
カフカのメッセージ
メッセージにおけるカフカメッセージ、バージョンV1は一部、キーと値の間の主な関係です。
（1）キー：メッセージがトピックのパーティションの指定されたパーティションに書き込む必要がある場合、キー値があればよいです。
（2）値：ここに格納された実際のメッセージの内容。
（3）メッセージの他のすべてのメタデータは、一般的には、ユーザに対して透過的で、気にしないでください。
メッセージデータを保存するために、カフカのByteBufferはヒープへのデータ・メッセージを保持するJavaオブジェクトを使用する場合に比べ、それはメモリ使用量を改善する、より省スペースであるように、コンパクトであるバイトのアレイを格納するために使用されます。
ログファイルとインデックスファイル
基本的な導入
話題のディレクトリパーティションの下に見て、それは次の特徴があり、そのログ、インデックスとtimeindex 3つの文書を発見しました。
（1）ログファイル名が指定された最初のメッセージのファイルオフセットであり、実際の長さが64ビットオフセットであるが、ここでは20ビットと、生産に対処するのに十分です。見ることができるように最初のログファイル名には、0で始まり、2番目のログファイルは、最初のログファイルは、0から4161280のオフセットからのメッセージを保存され、4161281です。
（2）名前インデックス+ログ+ timeindexファイルのセットは同じであり、ログ・ファイルが満杯デフォルト1Gであり、ローリングlog.segment.bytes =ことにより、新しいメッセージ作成、ブローカー端末を記録するログ形成されます1073741824指定は、この値を調整することができます。
（3）指標とtimeindexはログが圧延後、それは実際のサイズにトリミングされたときにちょうどそうわずか数百K.、最初のいくつかのインデックスファイルのサイズを確認、サイズの10Mを使用割り当てられます
# 一个分区目录下文件内容，参考文末书籍杜撰，主要为了说明概念
[root@hadoop01 /home/software/kafka-2/kafka-logs/football-0]# ll -h
-rw-r--r--. 1 root root 514K Mar 20 16:04 00000000000000000000.index
-rw-r--r--. 1 root root 1.0G Mar 17 03:36 00000000000000000000.log
-rw-r--r--. 1 root root 240K Mar 20 16:04 00000000000000000000.timeindex
-rw-r--r--. 1 root root 512K Mar 20 16:04 00000000000004161281.index
-rw-r--r--. 1 root root 1.0G Mar 17 03:36 00000000000004161281.log
-rw-r--r--. 1 root root 177K Mar 20 16:04 00000000000004161281.timeindex
-rw-r--r--. 1 root root 10M Mar 20 16:04 00000000000008749921.index
-rw-r--r--. 1 root root 390M Mar 17 03:36 00000000000008749921.log
-rw-r--r--. 1 root root 10M Mar 20 16:04 00000000000008749921.timeindexあなたはこれらのファイルを表示したい場合は、完全ないくつかの重要な情報を提供するシェルカフカを使用することができ、次のとおりです。
（1）は整数を増加オフセット。
外側の位置の増分バッチ（2）の相対位置は、メッセージのバイトオフセットとして理解されるべきです。
（3）CREATETIME：タイムスタンプ。
（4）マジック：2メッセージのこのタイプを表す0がV0のタイプの代表である場合、V1は、型を表す、V2です。マシンのこのタイプはV2ですが、また、一時的に詳細に教科書の最後を参照するには、特定の必要性を理解する上で参考V1に従ってすることができます。
compresscodec（5）：なし説明圧縮タイプが指定されていない、カフカは現在4つの選択、0-なし、1- GZIP、2-てきぱき、3- LZ4を提供します。
（6）CRC：チェックのすべてのフィールドのためのCRC値。
# 查看并打印log文件内容
[root@hadoop01 /home/software/kafka-2/kafka-logs/football-0]# ../../bin/kafka-run-class.sh kafka.tools.DumpLogSegments --files 00000000000000000004.log --print-data-log
Dumping 00000000000000000004.log
Starting offset: 4
baseOffset: 4 lastOffset: 4 baseSequence: -1 lastSequence: -1 producerId: -1 producerEpoch: -1 partitionLeaderEpoch: 49 isTransactional: false position: 0 CreateTime: 1584368524633 isvalid: true size: 85 magic: 2 compresscodec: NONE crc: 3049289418
baseOffset: 5 lastOffset: 5 baseSequence: -1 lastSequence: -1 producerId: -1 producerEpoch: -1 partitionLeaderEpoch: 49 isTransactional: false position: 85 CreateTime: 1584368668414 isvalid: true size: 73 magic: 2 compresscodec: NONE crc: 2267711305
baseOffset: 6 lastOffset: 6 baseSequence: -1 lastSequence: -1 producerId: -1 producerEpoch: -1 partitionLeaderEpoch: 49 isTransactional: false position: 158 CreateTime: 1584368679882 isvalid: true size: 78 magic: 2 compresscodec: NONE crc: 789213838
baseOffset: 7 lastOffset: 7 baseSequence: -1 lastSequence: -1 producerId: -1 producerEpoch: -1 partitionLeaderEpoch: 49 isTransactional: false position: 236 CreateTime: 1584368695371 isvalid: true size: 95 magic: 2 compresscodec: NONE crc: 703634716構造主義
（1）メッセージの内容は、ログファイルに格納されたログは、メッセージの記録担体です。録音メッセージは、シーケンシャル書き込みモード、参照画像の公式ウェブサイトを使用して、異なるパーティションのトピックがキューと考えることができる、アペンドログログファイルの最後に、の形でパッケージ化され、順次に送信されたメッセージを書かれています。図0,1,2,3他のデジタル・メッセージが増分数であるオフセットのパーティションであるpartition0で。
注また、ちょうど2つを混同学ぶために始めたときに、消費者は、消費の場所を指し、それは常に、主に次の消費者の向きを継続するためには、数字を更新されたオフセット、消費者をオフセットしています。絵に示されている公式サイトとして、消費者の消費量が9であるオフセット、オフセット個人消費は、B 11は、異なる消費者に引き渡されたが、自分の記録が分離オフセット。
インデックスファイルは、疎指標であるので、（2）は、ログログは各書き込み4K（log.index.interval.bytesセット）デフォルトのインデックスファイルに格納されたインデックスの位置は、、、、インデックスにファイルのインデックス情報を書き込みます。それは、各ログのインデックス情報を持っていません。
この図は、直接メッセージ+オフセット+位置実際の組成、インデックスファイルは、相対オフセット（4バイト）+位置（4バイト）構成によるデータ構造であり、ログファイル内のログを順次書き込まれ、オンラインに使用されていますシステムがそれに相対的なオフセットの最初のメッセージに関連し、ちょうど4バイトを保存し、ユーザーに対して透過的である、実際のオフセットに戻って計算する実際の必要性にスペース、外観を保存することができます。ログファイル名は、以下のゼロであり、及び3の相対オフセットのオフセット従って、実際の3 + 0,3残るからです。
そのインデックスの密度は高くありませんが、注文されたオフセットがまばらな指標については、カフカが実際のメッセージに対応するオフセット時間を見つけ、あなたは低い位置に対応するオフセットから低その後、オフセット、および最寄りに到達するために、インデックス半分で見つけることができます対応するメッセージを見つけるために、以降の実際のログファイルから開始します。= 5オフセットメッセージを検索するには、このデータは、低インデックスファイルを行くために34597を見つけ、その後、バイトが読み込まれたバイトまで4597からの読み込みを開始するために、ログファイルから4597をオフセットオフセット= 5、このデータは、それは時間を節約するために、直接の比からログファイルの読み取りを開始します。再トラバース時間複雑度はO（N）である場合にバイナリサーチ時間複雑度は、O（LGN）です。
注コンマのインデックスの数字が存在しないこと、コンマのこの画像は、理解を容易にするために添加されます。
あなたは、インデックスファイルを使用する場合（3）インデックスファイルのタイムスタンプが、その役割は、ユーザーが時間メッセージの一定の期間を照会できるようにすることです、それはまず、タイムスタンプ（8バイト）+相対オフセット（4バイト）のデータ構造であり、対応する相対オフセット見つけ、その後、対応するインデックスファイルに移動する必要時間は、ログファイルを移動する前に、位置情報を発見され、それはまた、上に述べたインデックスファイルを使用する必要があります。
しかし、ニュースプロデューサーの生産のためには、そのときのニュースの生産タイムスタンプを指定しないようにしよう、メッセージのタイムスタンプにつながる可能性があるメッセージのタイムスタンプは必ずしも順番ではありません指定することができます。
消費者団体やコーディネーター
ニュースの消費者支出、消費者は、オフセットが記録される場合には（ノートオフセットがパーティション化されていない、別のコンテキストが区別されなければならない）、消費者は、オフセット__consumer_offsetsと呼ばれる、特殊な内部のパーティションに格納され、それが役割です消費者のオフセットに格納され、コンシューマ・グループ。これは、パーティション50は50台のサーバに分散している場合、コピーを作成するために、50区（offsets.topic.num.partitionsセット）デフォルトを生成し、大幅に提出を相殺するために、消費者への圧力を緩和します。消費者の作成では、この特定のコンシューマ・グループを生成することができます。
# 如果只启动了hadoop03一个broker，则所有的50个分区都会在这上面生成
[root@hadoop03 /home/software/kafka-2/bin]# sh kafka-console-consumer.sh --bootstrap-server hadoop03:9092 --topic football --from-beginning --new-consumer質問があるので、消費者の保存最後にので、カフカは、コンシューマ・グループgroup.idに従ってパーティション番号を計算するMath.abs（groupId.hashCode（））50％を、どのパーティションを使用して決定するオフセットすべての消費者は、パーティションに保存されますオフセット下のコンシューマ・グループを決定することができます。
コンシューマ・グループ内のすべての消費者がもともとパーティションの下にニュースに提出？それをオフセット異なる消費者を区別するためにどのように、__consumer_offsets下の同じパーティションに提出されたオフセットを考えているので、キーはgroupIdを+で、再び質問がそうトピック+パーティション番号、消費者はオフセット値。キーあずかるエリアコード、パーティション番号は、個人消費のトピックの消費者団体のパーティション番号です注意してください。トピックの下に実際のケースパーティションので、唯一の消費者の消費者グループによって消費することができ、これはオフセット混乱の問題を心配されていません。
実際には、複数のパーティションの下のトピックが均等に消費者がバランスを取り戻すだろう、ダウンしているか、新しい消費者を追加する場合、消費者に耳を傾け、コーディネーター、で完了することが、消費者のグループで個人消費に配布し、パーティションは、消費者に再割り当てするために、特定の戦略を使用します。以下に示すように、コンシューマ・グループは、これまでの平均できるだけ、ブローカー、コンシューマ・グループのコーディネーターとして選挙は、消費者が自分の健康状態を把握様々なハートビートを監視する責任であるオフセット位置、および対応するパーティションリーダーの話題で保存されます消費者に、このような消費者を追加するなど、消費者の変化に基づいて、消費者のグループを、与える、コーディネーターのリバランスをトリガーされます。
そこ1つの詳細であり、コンシューマ・グループ間のコーディネーターはまた、どのように個々の消費者の間で暗黙の了解がグラブの人々のリソースがありません何をすべきか通信を行っ？次のように参照前任者がまとめました。
（1）選択された消費者グループコーディネータは、グループ参加要求を送信します。
（2）コーディネータは、消費者の消費者グループのリーダーを選択し、その後、消費者情報のトピックは、指導者に返されます。
トピックに基づいて（3）リーダーの消費者情報、同期グループの要求によってコーディネーターに戻ったコンシューマ・グループ独自の消費に沿ったプログラムのセットを指定します。
（4）コーディネーター後に消費者に配布割り当てを受信することになります。
（5）最後に、消費者のプログラムを持つことになり、各消費者は、消費のためにそれに準拠しています。
リバランス
リバランスの契約は、最終的に本は、それが最も一般的であり、消費者や消費者のグループが増加する場所なので、最初のレコードのみ3つのトリガ条件は、ある言及した、または休暇、コンシューマ・グループ内のトピックのパーティションを消費する方法と一致していますまたはベンの崩壊（それは人生に似ています）。他の二つ、1パーティションのトピック数は、使用カフカシェルパーティションを増加させ、消費者の話題があり、リバランスをトリガーする、新しい話題は、この規則の遵守が発生した場合には、定期的に試合に従ったものです。
これは、範囲、ラウンドロビン、粘着性のための3つの戦略を持っています。
TOPICA仮定P0〜P6のパーティションは、6つのパーティションの合計を持って、消費者のグループは、直感的な雰囲気の3つの戦略のための基礎として、3人の消費者を持っています。
（1）レンジ
Pythonの範囲に多少似、それは範囲だ、パーティション数に応じて分割され、結果は次のとおりです。
消費者1つのP0とP1、消費者2のP2 P3、消費者3 P4、P5
（2）ラウンドロビン
均等にランダムに分布され、わずか結果。
（3）スティッキー
上記の小さな問題2割り当てがあり、ダウンタイム、再配分後の消費者を持つことで、もともと新しい顧客に割り当てられますスマートにパーティションを過ごす消費者に属していました。そのような消費者のポリシーとして、それが再割り当てされたように、範囲3でハング、再割り当ては、消費者1、P0、P1、P2、消費者2 P3、P4、P5、P2となるであろう。オフセット消費者の管理の複雑さを考えると、それは粘着性の戦略は、消費者1 P0、P1〜P4消費者2 P2 P3 P5になるだろうであれば、古い習慣を維持したいしてみてください。
上記の、それはまた、より長いったらしい書き込み、必ずしも正しい理解ではなく、学習は継続的な理解と修正のプロセスです。
参考ボーエン：
（1）https://blog.csdn.net/xiaoyu_bd/article/details/52398265
（2）「アパッチカフカの本当の」