【メッセージキュー】Kafkaファイルストレージメカニズム

1.カフカとは

KafkaはもともとLinkedinによって開発されました。これは、飼育係の調整に基づく分散、パーティション化、マルチコピー、マルチサブスクライバー、分散ログシステムです（MQシステムとしても使用できます）。Web/ nginxログに一般的に使用できます。 Linkedinは、ログやメッセージングサービスなどにアクセスし、2010年にApache Foundationに貢献し、トップのオープンソースプロジェクトになりました。

商用メッセージキューのパフォーマンスは良いか悪いかであり、そのファイルストレージメカニズムの設計は、メッセージキューサービスの技術レベルと最も重要な指標の1つを測定することです。以下では、Kafkaのファイルストレージメカニズムと物理構造、およびその実際のアプリケーション効果の観点から、Kafkaがどのように効率的なファイルストレージを実現するかを分析します。

ブローカー：メッセージミドルウェア処理ノード。Kafkaノードはブローカーであり、複数のブローカーがKafkaクラスターを形成できます。
トピック：ページビューログ、クリックログなどの種類のメッセージがトピックの形式で存在する可能性があり、Kafkaクラスターが同時に複数のトピックの配布を担当する可能性があります。
パーティション：トピックの物理的なグループ化。トピックは複数のパーティションに分割でき、各パーティションは順序付けられたキューです。
セグメント：パーティションは物理的に複数のセグメントで構成されます。これらのセグメントについては、以下の2.2および2.3で詳しく説明します。
オフセット：各パーティションは、一連の順序付けられた不変のメッセージで構成され、パーティションに連続して追加されます。パーティション内の各メッセージには、オフセットと呼ばれる連続したシーケンス番号があります。これは、パーティション内のメッセージを一意に識別するために使用されます。

分析プロセスは、次の4つのステップに分かれています。

トピックのパーティションストレージ配布
部分的なファイルの保存方法
部分的なセグメントファイルストレージ構造
パーティション内のオフセットでメッセージを見つける方法

上記の4つのプロセスを詳細に分析することで、kafkaファイルの保存メカニズムの謎を明確に理解することができます。

2、Kafkaファイルストレージメカニズム

2.1トピックのパーティションストレージ配布

実験環境のKafkaクラスターにブローカーが1つしかない場合、xxx / message-folderはデータファイルストレージのルートディレクトリであり、Kafkaブローカーのserver.propertiesファイル構成（パラメーターlog.dirs = xxx / message-フォルダー）、たとえば、2つのトピック名を作成します。それらはreport_push、launch_infoであり、パーティションの数はpartitions = 4です。ストレージパスとディレクトリルールは次のとおりです。xxx/ message-folder

              |--report_push-0
              |--report_push-1
              |--report_push-2
              |--report_push-3
              |--launch_info-0
              |--launch_info-1
              |--launch_info-2
              |--launch_info-3

Kafkaファイルストレージでは、同じトピックの下に複数の異なるパーティションがあり、各パーティションはディレクトリです。パーティションの命名規則は、トピック名+連番です。最初のパーティション番号は0から始まり、最大数はパーティションの数です。マイナス1。マルチブローカーディストリビューションの場合は、kafkaクラスターパーティションディストリビューションの原理の分析を参照してください。

2.2部分的なファイルの保存方法

次の概略図は、パーティション内のファイルの保存方法を示しています。

各パーティション（ディレクトリ）は、同じサイズのセグメント（セグメント）の複数のデータファイルに均等に分散された巨大なファイルに相当します。ただし、各セグメントファイルのメッセージ数は必ずしも同じではありません。この機能により、古いセグメントファイルをすばやく削除できます。
各パーティションはシーケンシャルな読み取りと書き込みのみをサポートする必要があり、セグメントファイルのライフサイクルはサーバー構成パラメーターによって決定されます。

これの利点は、不要なファイルをすばやく削除し、ディスク使用率を効果的に改善できることです。

2.3部分的なセグメントファイルストレージ構造

読者は、セクション2.2からKafkaファイルシステムのパーティションストレージモードについて学習します。このセクションでは、パーティション内のセグメントファイルの構成と物理構造を詳細に分析します。

セグメントファイルは、それぞれインデックスファイルとデータファイルの2つの部分で構成されています。これら2つのファイルは1対1で対応し、ペアで表示されます。接尾辞「.index」と「.log」は、それぞれセグメントインデックスファイルとデータファイルとして表されます。。
セグメントファイルの命名規則：グローバルパーティションの最初のセグメントは0から始まり、後続の各セグメントファイルには、前のセグメントファイルの最後のメッセージのオフセット値という名前が付けられます。最大値は64ビットの長さ、19ビットの数字の長さであり、ゼロは数字を入力しないために使用されます。

次のファイルリストは、Kafkaブローカーで作成者が行った実験です。1つのパーティションを含むtopicXXXを作成し、各セグメントのサイズを500MBに設定し、プロデューサーを起動して、Kafkaブローカーに大量のデータを書き込みます。下の図2にあります。セグメントファイルリストの画像の説明上記の2つのルール：

図2のセグメントファイルファイルのペアを例にとると、セグメント内のインデックス<->データファイルの物理構造は次のとおりです。

上記の図３のインデックスファイルは、大量のメタデータを格納し、データファイルは、大量のメッセージを格納し、インデックスファイル内のメタデータは、対応するデータファイル内のメッセージの物理的オフセットアドレスを指す。インデックスファイルのメタデータ3,497を例にとると、3番目のメッセージがデータファイルに順番に示され（グローバルパーティションの368772番目のメッセージ）、メッセージの物理オフセットアドレスは497です。

上記の図3から、セグメントデータファイルは多くのメッセージで構成されていることがわかります。次に、メッセージの物理構造を次のように詳細に説明します。

パラメータの説明：

キーワード	説明する
8バイトオフセット	パーティション内の各メッセージには順序付けられたID番号があります。このID番号はオフセットと呼ばれ、パーティション内の各メッセージの位置を一意に決定できます。つまり、オフセットはパーティションのメッセージの数を表します
4バイトのメッセージサイズ	メッセージサイズ
4バイトCRC32	crc32を使用してメッセージを確認します
1バイトの「魔法」	今回リリースされたKafkaサービスプログラムプロトコルのバージョン番号を示します
1バイトの「属性」	独立したバージョンを示すか、圧縮タイプまたはエンコードタイプを識別します。
4バイトのキーの長さ	キーの長さを示します。キーが-1の場合、Kバイトのキーフィールドは入力されません。
Kバイトキー	オプション
値バイトペイロード	実際のメッセージデータを表します。

2.4パーティション内のオフセットでメッセージを見つける方法

たとえば、offset = 368776のメッセージを読むには、次の2つの手順を検索する必要があります。

最初のステップは、上記の図2に示すように、セグメントファイルを見つけることです。ここで、00000000000000000000.indexは最初のファイルを表し、開始オフセット（オフセット）は0です。2番目のファイルのメッセージボリュームの開始オフセット00000000000000000086769.indexは368770 = 368769 +1。同様に、3番目のファイル000000000000000737337.indexの開始オフセットは737338 = 737337 + 1であり、他の後続のファイルの後には類推が続きます。これらのファイルは、オフセット**ファイルリストをバイナリで検索することにより、特定のファイルをすばやく見つけることができます。offset = 368776の場合、000000000000000000368769.index | logを見つけます
2番目のステップは、セグメントファイルからメッセージを見つけることです。最初のステップは、セグメントファイルを見つけることです。offset= 368776の場合、メタデータの物理的な場所00000000000000368769.indexと物理的なオフセットアドレス00000000000000368769.logを見つけて、渡します。 00000000000000368769.log offset = 368776まで順番に検索します。

この利点は、上記の図3からわかります。セグメントインデックスファイルは、インデックスファイルのサイズを縮小するスパースインデックスストレージ方式を採用しています。mmapを介してメモリを直接操作できます。スパースインデックスは、のメタデータポインタを設定します。データファイルの対応する各メッセージ。高密度インデックスはより多くのストレージスペースを節約しますが、検索に時間がかかります。

3.Kafkaファイルストレージメカニズム-実際の操作効果

ラボ環境：

Kafkaクラスター：2つの仮想マシンで構成されます
cpu：4核
物理メモリ：8GB
ネットワークカード：ギガビットネットワークカード
jvmヒープ：4GB
Kafkaサーバーの構成と最適化の詳細については、kafkaserver.propertiesの構成の詳細を参照してください。

上の図5からわかるように、Kafkaは、実行中に多数のディスク読み取り操作を行うことはめったになく、主に定期的にバッチでディスクに書き込むため、ディスクの操作は非常に効率的です。これは、Kafkaファイルストレージでのメッセージの読み取りと書き込みの設計と密接に関連しています。Kafkaでのメッセージの読み取りと書き込みには、次の特徴があります。

メッセージを書く

メッセージは、Javaヒープからページキャッシュ（つまり、物理メモリ）に転送されます。
ディスクは非同期スレッドによってフラッシュされ、メッセージはページキャッシュからディスクにフラッシュされます。

メッセージを読む

メッセージはページキャッシュからソケットに直接転送され、送信されます。
対応するデータがページキャッシュから見つからない場合、ディスクIOはこの時点で生成され、ディスクロードメッセージからページキャッシュに送られ、ソケットから直接送信されます。

Kafkaの効率的なファイルストレージ設計機能

Kafkaは、トピック内の大きなパーティションファイルを複数の小さなファイルセグメントに分割します。複数の小さなファイルセグメントを使用すると、消費されたファイルを定期的にクリアまたは削除することが簡単になり、ディスク使用量が削減されます。
インデックス情報により、メッセージをすばやく見つけて、応答の最大サイズを決定できます。
すべてのインデックスメタデータをメモリにマッピングすることにより、セグメントファイルのIOディスク操作を回避できます。
インデックスファイルをまばらに保存することで、インデックスファイルのメタデータが占めるスペースを大幅に削減できます。

関連記事