Kafka のストレージメカニズムと信頼性

目次

1. Kafka の紹介とインストール構成

2. Kafka のストレージメカニズムと信頼性

Kafka のストレージメカニズムと信頼性

1. Kafka のストレージメカニズム

Kafka はトピックを使用してデータを保存します。トピックにはパーティションがあり、複数のコピーを持つことができます。パーティションはさらにいくつかのセグメントに分割されます。

いわゆるパーティションは、実際には Kafka の対応するストレージ ディレクトリに作成されるフォルダーです。フォルダーの名前はトピック名とパーティション番号を組み合わせたもので、番号は 0 から始まります。

[[228394]]

1. セグメント

いわゆるセグメントは、実際にはパーティションに対応するフォルダー内に生成されるファイルです。

パーティションは同じサイズの複数のセグメントに分割されます。これにより、パーティション データが複数のファイルに分割され、大きすぎるファイルの生成が防止されます。一方、これらのセグメント ファイルに基づいて履歴データを削除することで、効率を向上させることができます。

セグメントは、.log ファイルと .index ファイルで構成されます。

1. .ログ

.log ファイルは、データ セグメント データを保存するために使用されるデータ ファイルです。

2. .インデックス

.index は、対応する .log ファイルのインデックス情報を保存するインデックス ファイルです。

.index ファイルには、対応する .log ファイルのインデックス情報が保存されます。 .index ファイルを検索することで、.log ファイル内の現在のセグメントに保存されている各オフセットの開始位置を知ることができます。各ログには固定形式があり、オフセット番号、ログの長さ、キーの長さなどの関連情報が格納されます。この固定形式のデータを使用して、現在のオフセットの終了位置を決定し、データを読み取ることができます。

3. 命名規則

これら 2 つのファイルの命名規則は次のとおりです。

パーティション グローバルの最初のセグメントは 0 から始まり、後続の各セグメント ファイル名は、前のセグメント ファイルの最後のメッセージのオフセット値になります。値は 64 ビット、20 桁の長さです。数字がない場合は0が埋め込まれます。

2. データの読み取り

指定されたパーティション内の特定のオフセットに対応するデータの読み取りを開始するときは、まずオフセットを現在のパーティションのすべてのセグメントの名前と比較して、データがどのセグメントにあるかを判断し、次にセグメントのインデックス ファイルを検索してデータ ファイル内の現在のオフセットの開始位置を判断し、最後にこの位置からデータ ファイルを読み取ります。次に、データ形式に応じて結果を判断し、完全なデータを取得します。

2. 信頼性保証

1. AR

すべてのパーティションのレプリカを含む AR リストが Kafka で管理されます。 AR はさらに ISR と OSR に分けられます。

AR = ISR + OSR。

AR、ISR、OSR、LEO、HW などの情報は Zookeeper に保存されます。

1. 情報通信技術

ISR 内のレプリカはリーダー内のデータを同期する必要があります。同期が完了した場合にのみ、データが正常に送信されたとみなされ、外部からアクセスできるようになります。

この同期プロセス中は、データが書き込まれていても、外部からアクセスすることはできません。このプロセスは、LEO-HW メカニズムを通じて実現されます。

2. OSR

OSR 内のレプリカがリーダーのデータを同期しているかどうかは、データの送信には影響しません。 OSR のフォロワーはリーダーと同期しようと最善を尽くしますが、データ バージョンが遅れる可能性があります。

最初は、すべてのレプリカは ISR にあります。 Kafka の動作中に、レプリカの同期速度が replica.lag.time.max.ms で指定されたしきい値よりも遅い場合、レプリカは ISR から追い出され、OSR に保存されます。後で速度が回復した場合は、ISR に戻ることができます。

3. レオ

LogEndOffset: パーティション内の最新データのオフセット。データがリーダーに書き込まれると、LEO は最新のデータを直ちに実行します。 *** データ識別ビットに相当します。

4. 宿題

HighWatermark: 書き込まれたデータは、ISR 内のすべてのレプリカに同期された後にのみコミットされたと見なされます。 HW はその位置に更新され、HW より前のデータに消費者がアクセスできるようになり、同期されていないデータには消費者がアクセスできないようになります。これは、すべてのレプリカのデータ フラグを同期することと同じです。

リーダーがダウンすると、新しいリーダーは ISR リストからのみ選択できます。 ISR 内のどのレプリカが新しいリーダーとして選択されたとしても、HW より前のデータは認識されているため、リーダーが切り替えられた後も、コンシューマーは HW が以前に送信したデータを引き続き表示できます。

したがって、LEO は書き込まれた最新のデータの場所を表し、HW は同期されたデータを表します。外部からアクセスできるのは HW より前のデータのみです。

5. HW切り捨てメカニズム

リーダーがクラッシュし、新しいリーダーが選出された場合、新しいリーダーは以前のリーダーのすべてのデータが完全に同期されていることを保証できません。 HW 前のデータが同期されていることのみを保証できます。この時点で、すべてのフォロワーはデータを HW の場所に切り捨て、新しいリーダーとデータを同期してデータの一貫性を確保する必要があります。

クラッシュしたリーダーが回復し、新しいリーダーのデータが自身のデータと一致していないことが判明すると、クラッシュしたリーダーはクラッシュ前のハードウェアの場所にデータを切り捨て、新しいリーダーのデータを同期します。クラッシュしたリーダーが復活すると、フォロワーのようにデータを同期してデータの一貫性を確保します。

2. 生産者の信頼性レベル

上記の説明により、Kafka クラスター内の信頼性が保証されます。ただし、プロデューサーが Kafka クラスターにデータを送信する場合、データはネットワークを介して送信されるため、信頼性が低くなります。ネットワークの遅延、フラッシュの切断などにより、データが失われる可能性があります。

Kafka はプロデューサーに対して次の 3 つの信頼性レベルを提供し、さまざまな戦略を通じてさまざまな信頼性の保証を実現します。

実際、この戦略は、リーダーがメッセージの受信成功情報をクライアントに応答するタイミングを構成します。

request.required.acks パラメータによって設定されます:

1: プロデューサーはリーダーにデータを送信します。データを受信した後、リーダーは成功メッセージを送信します。メッセージを受信した後、プロデューサーはデータが正常に送信されたとみなします。成功メッセージが受信されない場合、プロデューサーはデータの送信が失敗したと見なし、データを自動的に再送信します。

リーダーがダウンすると、データが失われる可能性があります。

0: プロデューサーは、リーダーが成功メッセージで応答することなく、リーダーにデータを継続的に送信します。

このモデルは最高の効率性と信頼性を備えています。送信プロセス中またはリーダーがクラッシュすると、データが失われる可能性があります。

-1: プロデューサーがリーダーにデータを送信します。リーダーはデータを受信した後、ISR リスト内のすべてのレプリカがデータ同期を完了するまで待機し、その後プロデューサーに成功メッセージを送信します。成功メッセージが受信されない場合は、データ送信に失敗したとみなされ、データは自動的に再送信されます。

このモードは信頼性が高いですが、ISR リストにリーダーのみが残っている場合、リーダーに障害が発生するとデータが失われる可能性があります。

この時点で、min.insync.replicas を構成して、監視対象の ISR に少なくとも指定された数のレプリカが存在する必要があることを指定できます。デフォルト値は1ですが、2以上の値に変更する必要があります。

このように、プロデューサーがリーダーにデータを送信したが、ISR にリーダー自身しか存在しないことが判明した場合、データ書き込みが失敗したことを示す例外を受け取ります。この時点ではデータの書き込みはできないため、データが失われることはありません。

データは失われませんが、冗長データが生成される可能性があります。たとえば、プロデューサーはリーダーにデータを送信し、リーダーは ISR 内のフォロワーにデータを同期します。同期が半分終わると、リーダーがクラッシュします。この時点で、新しいリーダーが選択され、そのリーダーには今回提出されたデータの一部が含まれる可能性があります。プロデューサーは失敗メッセージを受信し、データを再送信します。新しいリーダーがデータを受信すると、データが複製されます。

3. リーダー選挙

リーダーがダウンすると、ISR 内のフォロワーが新しいリーダーとして選択されます。 ISR 内のすべてのレプリカがダウンしたらどうなるでしょうか?

次の構成でこの問題を解決できます。

unclean.leader.election.enable=false

戦略 1: レプリカを選択してリーダーにし、作業を続行する前に、ISR リスト内のレプリカがアクティブになるまで待つ必要があります。

クリーンでないリーダー選挙を有効にする=true

戦略 2: 生き残ったレプリカのいずれかを選択してリーダーになり、作業を続けます。このフォロワーは ISR 内にいない可能性があります。

戦略 1: 信頼性は保証されますが、可用性は低くなります。カフカは、*** が失敗した後にリーダーが復活した場合にのみ回復できます。

戦略 2: 可用性は高いが、信頼性は保証されない。生き残ったレプリカは引き続き機能しますが、データの不整合が発生する可能性があります。

4. Kafka の信頼性の保証

最大 1 回: メッセージは失われる可能性がありますが、繰り返し送信されることはありません。

少なくとも 1 回: メッセージは失われることはありませんが、繰り返し送信される可能性があります。

正確に 1 回: 各メッセージは 1 回だけ送信されます。

Kafka は少なくとも 1 回は保証するため、損失は発生しませんが、重複が発生する可能性があります。重複を解決するには、一意の識別子と重複排除メカニズムを導入する必要があります。 Kafka は一意の識別を実装するための GUID を提供しますが、組み込みの重複排除メカニズムは提供していません。開発者はビジネス ルールに基づいて重複を排除する必要があります。