パーティション内のすべてのレプリカは、総称して AR (Assigned Replica) と呼ばれます。リーダー レプリカとのある程度の同期を維持するすべてのレプリカ (リーダーを含む) は ISR (同期レプリカ) を形成し、ISR セットはAR セットのサブセットです。メッセージは最初にリーダー コピーに送信され、その後、フォロワー コピーは同期のためにリーダー コピーからメッセージをプルできます。同期期間中、フォロワー コピーはリーダー コピーよりもある程度遅れます。上記の「ある程度」とはヒステリシスの許容範囲を指し、パラメータで設定できます。リーダー レプリカとの同期が遅れすぎるレプリカ (リーダーを除く) は、 OSR (Out-Sync Relipcas) を形成します。AR=ISR+OSR からわかります。通常の状況では、すべてのフォロワー コピーはリーダー コピーとのある程度の同期、つまり AR=ISR を維持する必要があり、OSR セットは空です。
リーダー コピーは、ISR セット内のすべてのフォロワー コピーの遅延ステータスを維持および追跡する責任があります。フォロワー コピーが大幅に遅れたり失敗したりすると、リーダー コピーは ISR セットからそれを削除します。OSR セット内のフォロワー コピーがリーダー コピーに「追いつく」場合、ISR セット内のコピーはリーダーとして選出される資格があり、OSR セット内のコピーにはチャンスがありません (この原則は次のように調整できます)対応するパラメータ設定を変更します)
ISRスケーリング:
Kafka が起動すると、「isr-expiration」と「isr-change-propagation」という ISR に関連する 2 つのスケジュールされたタスクが開始されます。isr-expiration タスクは、各パーティションが ISR セットを縮小する必要があるかどうかを定期的にチェックします。この期間は、「replica.lag.time.max.ms」パラメータに関連しています。サイズはこのパラメータの半分です。デフォルト値は 5000ms で、ISR 内で無効なコピーが検出されると、ISR セットが削減されます。特定のパーティションの ISR セットが変更されると、変更されたデータは ZooKerper の対応する /brokers/topics//partition//state ノードに記録されます。ノード内のデータの例は次のとおりです。
{“controller_cpoch”:26,“leader”:0,“version”:1,“leader_epoch”:2,“isr”:{0,1}}
このうち、controller_epoch は現在の Kafka コントローラーを表し、epoch.leader は現在のパーティションのリーダー コピーが配置されているブローカーの ID 番号を表し、version はバージョン番号 (現在のハーフ コピーは 1 に固定されています) を表し、leader_epochは現在のパーティションのリーダー時代を表し、isr は変更された isr リストを示します。
さらに、ISR セットが変更されると、変更されたレコードは isrChangeSet にキャッシュされます。isr-change-propagation タスクは定期的に (固定値は 2500ms) isrChangeSet をチェックします。isrChangeSet に ISR がある場合は、変更レコードを設定しますを実行すると、Zookeeper の /isr_change_notification パスの下に isr_change で始まる永続的な順次ノード (/isr_change_notification/isr_change_0000000000 など) が作成され、isrChangeSet 内の情報がこのノードに保存されます。Kafka コントローラーは、ウォッチャーを /isr_change_notification に追加します。このノードの子ノードが変更されると、ウォッチャー アクションがトリガーされて、関連するメタデータ情報を更新し、更新されたメタデータ情報を管理するブローカー ノードに送信するようにコントローラーに通知します。最後に、/isr_change_notification のパスの下にある処理済みのノードを削除します。Watcher を頻繁にトリガーすると、Kafka コントローラー、Zookeeper、さらには他のブローカーのパフォーマンスに影響します。この状況を回避するために、Kafka は指定された条件を追加し、パーティション ISR セットが変更されたことを検出すると、次の 2 つの条件をチェックする必要があります。
(1). ISR セットが最後に変更されてから 5 秒以上経過しています。
(2). 最後に動物園の飼育員が書き込まれてから 60 秒以上が経過しています。
上記 2 つの条件のいずれかを満たしている人は、変更されたコレクションのターゲット ノードに ISR を書き込むことができます。
削減がある場合は補充があるため、Kafka はいつ ISR を拡張しますか?
フォロワー コピーがメッセージの同期を続けると、フォロワー コピー LEO は徐々に後退し、最終的にはリーダー コピーに追いつきます。この時点で、フォロワー コピーは ISR セットに入る資格があります。リーダーに追いつくための基準copy は、このコピーの LEO がリーダー コピー HW より小さいかどうかであり、リーダー コピー LEO とは比較されません。ISR が拡張されると、ZooKeeper の /broker/topics//partition//state ノードと isrChangeSet も更新され、その後の手順は ISR を縮小する場合と同じです。
ISR セットが増減する場合、または ISR セット内のレプリカ LEO が変更される場合、パーティション全体の HW に影響します。
以下の図に示すように、リーダー コピーの LEO は 9、フォロワー コピーの LEO は 7、フォロワー 2 コピーの LEO は 6 です。これら 3 つのコピーが ISR セット内にあると判断された場合、この場合、パーティションの HW は 6 です。フォロワー 3 が ISR セットから無効なコピーが削除されたと判断された場合、パーティションの HW は、リーダー コピーとフォロワー コピーの LEO の最小値である 7 になります。
LW は Low Watermark の略称で、一般に「ロー ウォーター マーク」として知られており、AR コレクション内の最小の logStartOffset 値を表します。レプリカのプル リクエスト (FetchRequest、新しいログ セグメントをトリガーする可能性があり、古いログ セグメントはクリーンアップされます)これにより、logStartoffset が増加し、削除リクエスト (DeleteRecordRequest) が LW の増加に寄与する可能性があります。
Kafka の HW、LEO、LSO、LW などは何を表しますか?
ISR は HW および LEO とも密接に関連しています。HW は High Watermak の略語で、一般的にハイ ウォーター マークとして知られています。特定のメッセージのオフセット (オフセット) を表し、コンシューマはこのオフセットより前にのみメッセージをプルできます。
以下のように、ログ ファイルを表します。このログ ファイルには 9 つのメッセージがあります。最初のメッセージのオフセット (LogStartOffset) は 0、最後のメッセージのオフセットは 8 です。オフセット 9 のメッセージは、点線のボックスは、次の「書き込まれるメッセージ」を表します。ログ ファイルの HW は 6 です。これは、コンシューマがオフセット 0 と 5 の間のメッセージのみをプルできることを意味し、オフセット 6 のメッセージはコンシューマには表示されません。
LEO は Log End Offset の略で、現在のログ ファイルに書き込まれる次のメッセージのオフセットを示します。上図のように、オフセットが 9 の位置が現在のログ ファイル LEO であり、 LEO のサイズは、現在のログ パーティションの最後のメッセージに相当し、メッセージのオフセット値に 1 を加えます。パーティション化された ISR セット内の各コピーは独自の LEO を維持し、ISR セット内の最小の LEO はパーティションの HW であり、コンシューマは HW より前のメッセージのみを消費できます。
以下の図に示すように、あるパーティションの ISR セットに、リーダー コピー 1 つとフォロワー コピー 2 つの計 3 つのコピーがあるとします。このとき、パーティションの LEO と HW は両方とも 3 です。メッセージ 3 と 4 がプロデューサーから送信されると、最初にリーダー コピーに保存されます。
メッセージがリーダー コピーに書き込まれた後、フォロワー コピーはメッセージ同期のためにプル メッセージ 3 とメッセージ 4 にプル リクエストを送信します。
同期プロセス中、異なるフォロワー コピーの同期効率も異なります。以下の図に示すように、ある時点で、フォロワー 1 はリーダー コピーに完全に追いつきますが、フォロワー 2 はメッセージ 3 のみを同期するため、リーダー コピーの LEO は 5、フォロワー 1 の LEO は 5、フォロワー 2 の LEO は次のようになります。 4. この場合、現在のパーティションの最小 HW 値は 4 となり、コンシューマは 0 から 3 までのオフセットを持つメッセージを消費できます。
以下の図に示すようにメッセージを書き込みます。すべてのレプリカはメッセージ 3 と 4 を正常に書き込みました。パーティション全体の HW と LEO は 5 なので、コンシューマはオフセット 4 のメッセージを消費できます。
Kafka のレプリケーション メカニズムは、完全な同期レプリケーションでも、純粋な非同期レプリケーションでもありません。実際、同期レプリケーションでは、このメッセージが送信の成功として確認される前に、すべての作業中のフォロワー コピーがコピーされている必要があります。レプリケーションはパフォーマンスに影響します。非同期レプリケーションの場合、フォロワー コピーはリーダー コピーからデータを非同期にコピーします。リーダー コピーによってデータが書き込まれる限り、データは正常にコミットされたとみなされます。この場合、フォロワー コピーが完全に複製されておらず、リーダー コピーより遅れている場合、リーダー コピーが突然ダウンすると、データ損失が発生します。Kafka は、この ISR メソッドを使用して、データの信頼性とパフォーマンスの関係のバランスを効果的にとります。
LSOとは何ですか?
LSO は特に LastStableOffset を指します。それは特にカフカに関するものです。
Consumer パラメータ —isolation.level、このパラメータはコンシューマ トランザクションの分離レベルを構成するために使用されます。文字列タイプ「read_uncommitted」および「read_committed」は、コンシューマが消費する場所を示します。これが「read_committed」に設定されている場合、コンシューマはトランザクションのコミットされていないメッセージを無視し、LSO (LastStableOffset) のみを消費できます。 Location、デフォルトでは「read_uncommitted」。HW (High Watermak) の場所に使用できます。
注: フォロワー コピーのトランザクション分離レベルも「read_uncommitted」であり、変更できません。
Kafka トランザクションを開いている間、プロデューサーはブローカーにいくつかのメッセージ (msg1、msg2、) を送信します。プロデューサーがトランザクションをコミットしない (CommitTransaction を実行する) 場合、isolation.level=read_committed がコンシューマーに表示されます。これらのメッセージはそれほど多くはありませんが、isolation.level=read_uncommitted が表示されます。トランザクション内の最初のメッセージの位置は、firstUnstableOffset (つまり、msg1 の位置) としてマークできます。
この LSO は、Kafka によって消費される量 (つまり、Kafka、Log、多くの場合 Kafka の蓄積とも呼ばれます) の計算にも影響します。以下に示すように。
図では、各パーティションの Lag は HW-ConsumerOffset の値に等しく、ComsmerOffset は消費電流の変位を表します。もちろん、これは通常の場合のみです。メッセージにトランザクションが導入された場合、ラグは別の方法で計算されます。
コンシューマクライアントのisolation.levelパラメータが「read_uncommitted」（デフォルト）に設定されている場合、Lagの計算方法は影響を受けません。このパラメータが「read_committed」に設定されている場合、計算にはLSOを導入する必要があります。
未完了のトランザクションの場合、LSO の値はトランザクション内の最初のメッセージの位置(firstUnstableOffset)に等しくなります。
完了したトランザクションの場合、その値は HW に相当するため、次の結論を導き出すことができます: LSO≤HW≤LEO
したがって、パーティション内の未完了のトランザクションの場合、コンシューマ クライアントのisolation.levelパラメータは「read_committed」として設定されます。
" の場合、対応する Lag は LSO-CommsumerOffset の値に等しくなります。