前回のブログでは、Kafka分散クラスターを構築しました[Kafkaエントリーから放棄シリーズ2] Kafkaクラスターを構築し、メッセージを正常に送信および消費しました。これにより、最初にKafkaの機能が検証されました。次に、最初の記事[Kafka from放棄シリーズの開始1]概要と基本アーキテクチャの簡単な理論、および 2番目の記事の実践に基づいて、Kafkaのアーキテクチャといくつかの戦略について詳しく説明し始めました。このブログでは、プロセス全体とファイルストレージメカニズムに焦点を当てています。次のいくつかの記事プロデューサー戦略、コンシューマー戦略、およびいくつかの高度な機能を個別に紹介します
Kafkaワークフロー
基本的な概念を学習することで、Kafkaのメッセージはトピックに分割され、トピックは論理的にパーティションに分割できることがわかります。トピックとパーティションについては、次の点に注意する必要があります。
- トピックはメッセージの一種と考えることができます。各トピックは複数のパーティションに分割され、各パーティションはストレージレベルの追加ログファイルです。
- パーティションにパブリッシュされたメッセージは、ログファイルの末尾に追加されます。ファイル内の各メッセージの位置は、オフセット（オフセット）と呼ばれます。オフセットは、メッセージを一意にマークする長い数字です。
- Kafkaメカニズムでは、プロデューサープッシュからのメッセージがパーティションに追加されます。これはシーケンシャル書き込みディスクメカニズムであり、ランダム書き込みメモリよりもはるかに効率的です
- コンシューマーグループの各コンシューマーは、消費したオフセットをリアルタイムで記録するため、エラーが回復したときに、最後の位置から継続して消費できます。
- Kafka は、Partion内のメッセージの順序のみを保証し、グローバルトピックのメッセージの順序は保証できません。
全体的なプロセスを次の図に示します。
では、なぜパーティションの概念があるのでしょうか。これは主に、すべての分散ミドルウェアの共通の特徴である負荷分散と水平方向の拡張です。トピックは論理的な概念にすぎず、プロデューサーとコンシューマー向けであり、パーティションは物理的な概念です。トピックがパーティション化されず、メッセージをトピックのブローカーに格納する場合、トピックのすべての読み取りおよび書き込み要求はこのブローカーによって処理され、スループットはボトルネックに陥る可能性が高く、明らかに高スループットと一致していませんアプリケーションシナリオの量。したがって、トラフィックを異なるサーバーに分散するために、パーティション化する必要があります。
Kafkaファイルストレージメカニズム
もちろん、パーティションの場合でも、メッセージの量が多すぎると、目詰まりのリスクがあるため、もちろん古いメッセージから定期的にメッセージをクリーンアップする必要があります。パーティションが1つしかない場合は、完全にクリアする必要があります。これは、メッセージファイルのメンテナンスと消費されたメッセージのクリーンアップに深刻な影響を与えます。したがって、パーティションをさらに物理的に細分割する必要があります。したがって、パーティションはセグメント単位でさらに細分化する必要があります。各パーティション（ディレクトリ）は、複数の同じサイズのセグメントデータファイルに均等に分散された巨大なファイルと同等です（各セグメントファイルのメッセージ数は必ずしも必要ではありません）等しい）この機能により、古いセグメントの削除も容易になり、消費されたメッセージのクリーニングが容易になり、ディスク使用率が向上します。各パーティションは、シーケンシャルな読み取りと書き込みのみをサポートする必要があります。
パーティションとセグメント
次に、物理ストレージでの外観を確認するメッセージを送信します
。3つのメッセージ：hello、dashuaige、hhh。ストレージディレクトリを開くと、103マシンで、インデックスとログのセットであることがわかります。これは、セグメントのコンテンツです。
セグメントファイルは、「。index」ファイルと「.log」ファイルの2つの部分で構成され、それぞれセグメントインデックスとして表されます。ファイルとデータファイル。これら2つのファイルのコマンドルールは次のとおりです。グローバルパーティションの最初のセグメントは0から始まり、後続の各セグメントファイルには、前のセグメントファイルの最後のメッセージのオフセット値という名前が付けられ、値のサイズは64ビット、数値の長さは20ビットです。 0で埋められた番号はありません。ここにはデータが1つしかないため、0から始まります。ログファイルを開くと
、次のように表示されます。文字化けしていますが、連続して送信されたメッセージが漠然と表示されています。全体的なストレージアーキテクチャは次のとおりです。
セグメントストレージ構造
上記のセグメント配置ファイルの理解を通じて、基本的にはセグメントの構造を理解しました。もちろん、私はここには見えない単一のセグメントのためにここにいます。これはインターネットからの多数のファイルの例です：
//第一段segment，起始位置为0
00000000000000000000.index
00000000000000000000.log
//第一段segment，起始位置为170410
00000000000000170410.index
00000000000000170410.log
//第一段segment，起始位置为239430
00000000000000239430.index
00000000000000239430.log
次の図に示すように、上記のセグメントファイルを例として、セグメントの「.index」ファイルと「.log」ファイルの対応する関係を示します。00000000000000170410：
上記のように、「。index 」インデックスファイルには大量のメタデータ「」が格納されています。 「ログ」データファイルには多数のメッセージが格納され、インデックスファイル内のメタデータは、対応するデータファイル内のメッセージの物理オフセットアドレスを指します。「.index」インデックスファイルのメタデータ[3、348]を例にとると、「。log」データファイルは3番目のメッセージ、つまりグローバルパーティションの170410 + 3 = 170413メッセージを表します。物理オフセットアドレスは348です[ この物理オフセットアドレスはオフセットではなく、グローバルオフセットは170413です]
分割されたメッセージをすばやく見つける
メッセージはPartionでセグメントに分割されているので、メッセージの位置をすばやく見つけて正確に操作するにはどうすればよいですか？上の画像を例に取って、offset = 170418のメッセージを読んでください。
- まず、セグメントファイルを見つけます。00000000000000000000.indexは最初のファイル、2番目のファイルは00000000000000170410.index（開始オフセットは170410 + 1 = 170411）、3番目のファイルは00000000000000239430.index（開始オフセット）です。 239430 + 1 = 239431）なので、このオフセット= 170418は2番目のファイルに入ります。他の後続のファイルの後には、類推が続き、名前が付けられ、オフセットによって配置されます。その後、特定のファイルの場所を、バイナリ検索方法に従ってすばやく見つけることができます。
- 第二に、00000000000000170410.indexファイルの170418 -170410 = 8によると、それはセグメントの8番目のメッセージであり、** [メッセージオフセット、物理オフセット]を取得するためのバイナリ検索方法に従ってインデックスが再度配置されています。 **座標[8,1325]は、読み取りのために00000000000000170410.logファイルの1325の位置にあります。
- 1325の位置を見つけたら、メッセージを順番に読み取り、このメッセージの読み取りを必ず完了してください[このメッセージはどこで終了しますか？]メッセージの物理構造は解決され、メッセージには次の固定物理構造が含まれます。オフセット（8バイト）、メッセージ本文サイズ（4バイト）、crc32（4バイト）、マジック（1バイト）、属性（1バイト）、キー長（4バイト）、キー（Kバイト）、ペイロード（Nバイト）およびその他のフィールドを決定できます。メッセージのサイズ、つまり読み取りが終了する場所。
以上がメッセージの詳細な検索方法ですが、インデックス方式により、カフカがディスクにシーケンシャルに書き込んだ後でも、対応するメッセージを素早く見つけることができます。
このブログでは、Kafkaのワークフローとストレージメカニズムについて説明します。実際、Kafkaの場合、プロデューサーとコンシューマーに反映される戦略が増えます。次の2つのブログでは、プロデューサー戦略とコンシューマー戦略をそれぞれ紹介します。
コンテンツの一部はhttps://gitbook.cn/books/5ae1e77197c22f130e67ec4e/index.htmlを参照します