1 つの記事が Kafka をマスターするのに役立ちます。基本的なスキルはやらないでください 6

著者: ビッグボウルワイドヌードル

この記事は、chatGPT の要約に基づいており、さまざまなブログや偉人の個人 Web サイトの共有によって補足され、最終的に独自の口語的な要約を開始し、Kafka の理論的知識の完全かつ体系的なコレクションを作成するよう努めています。この記事は、基本的な名詞、高度な名詞の分析、Kafka のメカニズムとシナリオの分析、最後に Kafka ソースコードパッケージの簡単な分析の 5 つのモジュールに分かれており、より深く幅広い内容を実現します。

Kafka の基本的な名詞解析

Kafka とは何ですか? また、ブローカー、トピック、パーティション、プロデューサー、およびコンシューマーとは何ですか?

Kafka は、大量のデータとリアルタイムデータストリームの処理に一般的に使用される、高性能でスケーラブルな分散メッセージキューシステムです。

ブローカー: Kafka クラスターは 1 つ以上の独立したサーバーノードで構成され、各ノードはブローカーと呼ばれます。各ブローカーは、メッセージの保存、受信、転送 (受信と送信)を担当します。これらは一緒になって分散メッセージングシステムを形成します。
トピック:トピックは、Kafka のメッセージのカテゴリまたはデータストリームの名前です。メッセージはトピックごとに分類され、公開されます。トピックは、一意の識別子を持つメッセージキューと考えることができます。たとえば、ログメッセージを受信するトピックと、ユーザーアクティビティメッセージを受信するトピックが 1 つずつあるとします。
パーティション: 各トピックは 1 つ以上のパーティションに分割できます。パーティションはトピックの物理的な分割であり、データの並列処理と分散ストレージを実装するために使用されます。各パーティションは、順序付けられた不変のメッセージのシーケンスです。パーティションはディスク上にファイルとして保存され、ブローカーによって管理されます。
プロデューサー: プロデューサーは、メッセージを生成し、Kafka トピックに発行するアプリケーションまたはシステムです。プロデューサは特定のトピックにメッセージを送信する責任を負い、オプションで特定のパーティションにメッセージを送信できます。プロデューサはメッセージをブローカーに送信し、ブローカーはメッセージを永続化し、構成されたレプリケーションポリシーに従って他のブローカーにレプリケートします。
Consumer : コンシューマは、Kafka トピックからメッセージを読み取るアプリケーションまたはシステムです。コンシューマは 1 つ以上のトピックをサブスクライブし、トピックの 1 つ以上のパーティションからメッセージを読み取ります。各コンシューマは独立したコンシューマグループ識別子を持っているため、複数のコンシューマがトピックからのメッセージを並行して消費できます。

簡単にまとめると、Kafka は一般的に使用される高性能の分散メッセージキューであり、主にブローカー、トピック、パーティション、プロデューサー、コンシューマーの概念が含まれています。エージェントは、Kafka クラスター内の各サーバーノードの名前であり、メッセージの保存、受信、転送を担当します。Kafka はパブリッシュとサブスクライブに基づいたメッセージングシステムであり、プロデューサーとコンシューマーの間の架け橋がテーマです。各トピックは少なくとも 1 つのパーティションに分割でき、各パーティションは順序付けられたメッセージのセットであり、パーティションの数は最大並列度も表します。プロデューサは、メッセージを生成して Kafka トピックにパブリッシュするアプリケーションまたはシステムであり、コンシューマは、Kafka トピックからメッセージを読み取るアプリケーションまたはシステムです。

ニッチな知識を追加します。

パーティションのデータファイル (オフセット、メッセージサイズ、データ)。パーティション内の各メッセージには、次の 3 つの属性が含まれます: offset、MessageSize、data (ここで、offset は、このパーティション内のメッセージのオフセットを表します。Offset は、パーティションデータファイル内のメッセージの実際の格納場所ではなく、論理 A 値です) offset はパーティション内のメッセージの ID、MessageSize はメッセージコンテンツデータのサイズを表し、data はメッセージの特定のコンテンツであると考えることができます。
データファイルのセグメント化 (順次読み取りと書き込み、セグメントの名前付け、バイナリ検索)。パーティションは物理的に複数のセグメントファイルで構成されており、各セグメントは同じサイズで、順番に読み書きされます。各セグメントデータファイルには、セグメント内の最小オフセットを使用した名前が付けられ、ファイル拡張子は .log です。このようにして、指定されたオフセットを持つメッセージを検索するときに、二分探索を使用して、メッセージが配置されているセグメントデータファイルを見つけることができます。
データファイルインデックス (セグメント化されたインデックス、スパースストレージ)。Kafka は、セグメント化されたデータファイルごとにインデックスファイルを作成します。ファイル名は、ファイル拡張子が .index であることを除き、データファイルと同じです。インデックスファイルは、データファイル内のメッセージごとにインデックスを作成するのではなく、スパースストレージを使用して、データの特定のバイトごとにインデックスを作成します。これにより、インデックスファイルが多くのスペースを占有することがなくなり、インデックスファイルがメモリ内に残ることができます。

Kafka の高度な用語分析

コントローラ

Kafka が開始されると、現在の Broker 情報が Zookeeper に登録されます。最初に登録した人がコントローラーです。登録されたスレーブノードのデータを (リスニングメカニズムを通じて) 読み取り、クラスターのメタデータ情報を生成し、これを配布します情報を他のノードサーバーに送信し、他のサーバーがクラスター内の他のメンバーの存在を認識できるようにします。

コーディネーター

Kafka のコーディネーターは、コンシューマーグループとプロデューサーの間のトランザクションの調整と管理を担当する重要なコンポーネントです。これにより、コンシューマグループがパーティションを正しく割り当てて消費できるようになり、プロデューサトランザクションの正しいコミットとリカバリが管理されるようになります。

消費者グループコーディネーター (グループコーディネーター) : 各消費者グループには消費者グループコーディネーターがいます。これは、消費者グループのさまざまな活動の調整と管理を担当する Kafka ブローカーです。コンシューマグループコーディネーターは次のタスクを実行します。

新しいコンシューマを登録する: コンシューマがコンシューマグループに参加すると、コンシューマグループ自体をコンシューマグループコーディネータに登録し、コンシューマグループの割り当てポリシーを受け取ります。
パーティションの割り当て: コンシューマグループ内のコンシューマの数が変化した場合 (新しいコンシューマの参加や古いコンシューマの離脱など)、コンシューマグループコーディネーターは、コンシューマにパーティションを再配布する責任を負います。パーティション割り当て戦略を使用して、ロードバランシングとフォールトトレランスを実現するためにコンシューマにパーティションを割り当てる方法を決定します。
コンシューマグループのオフセットの管理: コンシューマグループコーディネーターは、各パーティション上のコンシューマグループの消費オフセットを追跡および管理する責任もあります。コンシューマグループのオフセットを Kafka にコミットし、切断またはリバランス後にコンシューマグループが最後のオフセットから正しく消費を継続できるようにします。

プロデューサートランザクションコーディネーター: Kafka には、Kafka トランザクションの調整の管理を担当するプロデューサートランザクションコーディネーターもあります。プロデューサートランザクションコーディネーターは次のタスクを実行します。

トランザクションの初期化: プロデューサはトランザクションを開始すると、プロデューサトランザクションコーディネーターと対話して、トランザクション ID と対応するリーダーコピーを取得します。
トランザクションをコミットする: トランザクションが完了すると、プロデューサはトランザクションのコミット要求をプロデューサトランザクションコーディネーターに送信します。コーディネーターは、トランザクション内のすべてのメッセージが正常に書き込まれたことを確認し、トランザクションのコミットステータスを Kafka ログに書き込みます。
トランザクション回復: トランザクション中にプロデューサが失敗するかクラッシュした場合、プロデューサトランザクションコーディネーターは、トランザクションの整合性を確保するために回復プロセスを調整する責任があります。

消費者グループ

Consumer Group は、メッセージコンシューマを編成および管理するために使用されます。公式の紹介によると、コンシューマグループは、Kafka によって提供されるスケーラブルでフォールトトレラントなコンシューマメカニズムです。コンシューマグループには複数のコンシューマインスタンスが含まれており、各インスタンスはメッセージを並行して消費できます。メッセージキューシステムは、高いスループットと負荷分散を実現するために、グループ内のコンシューマインスタンスにメッセージを分散します。パーティションの数を超える同じコンシューマグループ内のコンシューマはメッセージを消費できないことに注意してください。そのため、コンシューマの数は通常、パーティションの数と同じに設定されます。もちろん、追加のコンシューマはフェイルオーバーのバックアップとして使用することもできます。。

Kafka はコンシューマグループ設計を使用して 2 つのメッセージキューモデルを同時に実装していることに言及する価値があります。すべてのインスタンスが同じグループに属している場合、それはキューモデルです。すべてのインスタンスが異なるグループに属している場合、パブリッシュ/サブスクライブモデル (1 対多) が実装されます。

リバランス

リバランスとは、コンシューマグループ内のコンシューマインスタンスが変更されたときに、メッセージキューシステムが各コンシューマインスタンスに分散されたメッセージを再分散するプロセスを指します。新しいコンシューマインスタンスの追加、または障害やハートビートタイムアウトによる古いインスタンスの終了により、リバランスが発生します。再バランス処理には時間がかかるため、再割り当て期間中に一部のメッセージが処理されない場合があります。

リバランスプロセスは、結合と同期の2 つのステップに分かれています。

参加フェーズでは、すべてのコンシューマーインスタンスがブローカーのコンシューマーコーディネーター (グループコーディネーター) に参加リクエストを送信します。すべての成功したリクエストを取得した後、コーディネーターはリーダーとなるコンシューマーインスタンスをランダムに選択し、グループメンバー情報とトピック情報をリーダーに送信し、消費割り当て計画を策定する責任を負います。
同期フェーズでは、コンシューマリーダーは消費計画の割り当てを開始します。つまり、どのコンシューマがどのトピックとどのパーティションを消費するかを決定します。割り当てが完了すると、リーダーは計画を SyncGroup リクエストにカプセル化して送信します。コーディネーター。非リーダーも SyncGroup リクエストを送信しますが、その内容は次のとおりです: 空。割り当て計画を受信した後、コーディネーターはその計画を SyncGroup の応答に詰め込み、各コンシューマーに送信します。このようにして、グループは、どのパーティションを使用する必要があるかを知っています。

メッセージ

Kafka メッセージは、固定長のヘッダーと可変長のメッセージ本文で構成されます。

ヘッダ部はマジック（ファイル形式）1バイトとCRC32（ボディメッセージ本文が正常かどうかを判定するために使用）4バイトで構成されます。magic の値が 1 の場合、magic と crc32: 属性の間にさらに 1 バイトのデータが存在します (圧縮するかどうか、圧縮形式などのいくつかの関連属性を保存します)。magic の値が 0 の場合、存在しません属性属性

本文は、次のような特定のキー/値メッセージを含む、N バイトで構成されるメッセージ本文です。

キー (オプション): メッセージのキー。パーティション化とメッセージの順序付けに使用されます。キーが指定されている場合、Kafka はキーのハッシュに基づいてメッセージを特定のパーティションにルーティングし、同じキーを持つメッセージの書き込みと読み取りが同じパーティションに行われるようにします。
値: 実際のメッセージの内容。通常はバイト配列または文字列です。これは、転送して処理する必要があるデータです。
オフセット: パーティション内のメッセージの一意の識別子。パーティション内のメッセージの位置を示します。コンシューマはオフセットを使用して消費の進行状況を追跡し、メッセージが見逃されないようにできます。
パーティション (オプション): メッセージが属するパーティション番号。パーティションが指定されていない場合、Kafka はプロデューサーによって構成されたパーティション化ポリシーに基づいてパーティションを自動的に割り当てます。
タイムスタンプ (オプション): メッセージのタイムスタンプ。メッセージが作成された時刻を示します。タイムスタンプは、メッセージが実際に生成された時刻であることも、プロデューサーがメッセージを送信するときに明示的に設定されたカスタム時刻であることもできます。
ヘッダー (オプション): メッセージに関連するメタデータを保存するために使用されるキーと値のペアのセット。ヘッダーには、メッセージのソース、タイプ、バージョンなどのさまざまなカスタム情報を含めることができます。

トピックのトピック（__consumer_offsets）

Kafka では、__consumer_offsets はコンシューマグループのオフセット情報を格納するために使用される内部トピックです。これは、特定のトピックのパーティション内で消費する消費者の進行状況を追跡するために使用されます。__consumer_offsets トピックの各メッセージには、次の情報が含まれます。

コンシューマグループID
トピック名
パーティションID
コンシューマグループ内のコンシューマのオフセット (オフセット)
メッセージ送信のタイムスタンプ (タイムスタンプ)

この内部トピックを維持することにより、Kafka はパーティション内のコンシューマグループの使用の進行状況を追跡および管理し、コンシューマがメッセージを正しく処理して障害回復を達成できるようにします。コンシューマーは開始時にトピックからオフセット情報を読み取り、どのオフセットでメッセージの消費を開始するかを決定します。メッセージが処理され、コンシューマがオフセットをコミットすると、この情報もそれに応じて更新されます。同時に、Kafka のコンシューマーコーディネーターは、__consumer_offsets トピックの更新と保守を担当します。コンシューマがコンシューマグループに参加したり脱退したりするためのリクエストと、コンシューマがオフセットを送信して取得するための操作を処理します。

データファイルとログファイル

データファイル：

Kafka では、データファイルは通常、実際のメッセージデータが保存されているKafka サーバー上のファイルを指します。Kafka は、セグメント化されたストレージを使用してメッセージを管理します。各トピックは複数のパーティションに分割され、各パーティションは一連のデータファイルに再分割されます。これらのデータファイルは、メッセージのコンテンツの保存に使用されます。メッセージがプロデューサーによって Kafka クラスターに送信されると、メッセージは適切に分割されたデータファイルに追加されます。コンシューマは、これらのデータファイルからメッセージを読み取ることができます。

ログファイル：

Kafka では、ログファイルは通常、メッセージを永続化するために使用されるKafka ブローカー上のファイルを指します。Kafka はメッセージの永続化にログを使用し、追加ベースのログストレージモデルを使用します。各トピックの各パーティションには、メッセージを順番に保存する対応するログファイルがあります。ログファイル内のメッセージは、追加方式で書き込まれ、読み取られます。ログファイルが特定のサイズ制限または時間制限に達すると、Kafka はログファイルを閉じ、メッセージの保持を継続するために新しいログファイルを作成します。

ログインデックス

Kafka がログレベルで TB レベルのデータをサポートできる理由は 2 つあります。1 つは順次追加ベースのログ書き込み + スパースハッシュインデックス(データファイルと同様、どちらも最適化にインデックスの概念を使用します)。Kafka のスパースハッシュインデックスは、メモリスペースを節約しながらメッセージの位置と取得を高速化するために、キーメッセージオフセットを一定の間隔で記録するデータ構造です。

メッセージが Kafka のログファイルに書き込まれると、メッセージはパーティションのログの末尾に順番に追加されます。各パーティションには対応するスパースハッシュインデックスがあり、重要なメッセージオフセットが記録されます。これらのインデックスは、各メッセージのオフセットを記録しませんが、一定の間隔でいくつかのキーメッセージ (通常は連続メッセージ) のオフセットを記録します。スパースハッシュインデックスを使用する利点は、インデックスのサイズを大幅に削減できるため、メモリ領域を節約できることです。

コンシューマが特定のオフセットでメッセージを読み取る必要がある場合、まずスパースハッシュインデックスを通じてターゲットオフセットに最も近いレコードを見つけ、次にターゲットメッセージが見つかるまでログファイルを線形にスキャンします。この方法は完全なインデックス検索よりも遅くなりますが、スパースハッシュインデックスの存在により、全体的な検索速度は依然として非常に効率的になります。

Kafka のメカニズム分析

Kafkaのマルチレプリカの仕組みを詳しく解説

Kafka のレプリカ (レプリカ) は、Kafka ノードに障害が発生したときにデータが失われないようにするためのデータ冗長性と障害回復メカニズムを提供し、高スループットのデータ読み取りおよび書き込み操作をサポートします。

各パーティションには複数のコピーを持つことができ、複数のコピーは異なるブローカーノードに分散されます。パーティションの最初のレプリカはリーダーレプリカ (リーダーレプリカ) と呼ばれ、他のレプリカはフォロワーレプリカ (フォロワーレプリカ) と呼ばれます。

リーダーレプリカ: 各パーティションのリーダーレプリカは、そのパーティションに対するすべての読み取りおよび書き込みリクエストを処理する責任があります。プロデューサはリーダーレプリカにメッセージを送信し、コンシューマはリーダーレプリカからメッセージを読み取ります。リーダーレプリカは、データをフォロワーレプリカに複製する役割も果たします。

フォロワーコピー: フォロワーコピーは、リーダーコピーのコピーです。リーダーレプリカからのデータを同期します。フォロワーレプリカはクライアントからの読み取りおよび書き込みリクエストを処理せず、冗長性とフェイルオーバーを提供するためにのみ使用されます。(同様のレプリカの概念を設計する場合、多くの分散システムはマスターノードへの負荷を共有するために少なくとも読み取り機能を提供することは言及する価値があります。それに比べて、Kafka のレプリカメカニズムはより厳密です)。

データレプリケーション: リーダーレプリカはメッセージをローカルログ (ログ) に書き込み、レプリケーションメカニズムを通じてそのメッセージをフォロワーレプリカのログにコピーします。レプリケーションでは、同期レプリケーションと非同期レプリケーションの 2 つのモードを使用できます。

同期レプリケーション: リーダーレプリカは、メッセージがコミットされたと見なす前に、メッセージが正常にレプリケートされたことをすべてのフォロワーレプリカが確認するのを待ちます。このモードは最も強力なデータ保証を提供しますが、書き込み遅延にある程度の影響を与えます。
非同期レプリケーション: リーダーレプリカは、ローカルログにメッセージを書き込んだ後、フォロワーレプリカからの確認を待たずに、ただちに成功応答を返します。このモードでは書き込み遅延が短くなりますが、特定の状況下ではデータ損失が発生する可能性があります。

レプリカの同期: フォロワーコピーとリーダーコピーの一貫性を維持するために、Kafka はログベースのレプリケーションメカニズムを使用します。フォロワーレプリカは、リーダーレプリカからログエントリをコピーし、それらを自分自身のログに順番に追加します。レプリケーションプロセスでは、まだコピーされていないログセグメントのみをプルする効率的な増分プル方式が使用されます。

フェイルオーバー: リーダーレプリカに障害が発生すると、Kafka は自動的にフォロワーレプリカを新しいリーダーとして選択します。パーティション内のすべてのレプリカは、総称して AR (割り当てられたレプリカ) と呼ばれます。選択プロセス中、Kafka はパーティションの ISR (In-Sync Replica) セット、つまり、リーダーレプリカとのデータ同期を維持するフォロワーレプリカのセットを使用します。遅延したフォロワーは OSR (Outof-Sync Replicas) リストに保存され、新しく追加されたフォロワーも最初に OSR に保存されます。AR=ISR+OSR。ISR 内のフォロワーコピーのみが新しいリーダーになる資格があります。

リーダーレプリカに障害が発生した場合、Kafka は ISR からフォロワーレプリカを選択して新しいリーダーになります。すべての ISR がダウンしている場合、AR から最初に応答したレプリカがリーダーとして選択されるため、メッセージの損失または重複が発生することに注意してください。
フォロワーレプリカに障害が発生した場合、Kafka はそれを ISR から削除し、他のフォロワーレプリカとの同期を継続します。

簡単にまとめると、Kafka のコピーメカニズムはデータの冗長性と障害回復機能を提供し、各パーティションは複数のコピーを持つことができ、異なるノードに分散することができます。レプリカの役割はリーダーとフォロワーに分かれており、リーダーは実際の読み取りと書き込み、およびフォロワーレプリカへのデータの同期を担当します。同期と非同期の 2 つのモードがあります。フォロワーはデータの冗長性とフェイルオーバーの回復のみを担当します。すべてのレプリカは総称して AR と呼ばれます。一貫したデータ同期を持つ一連のフォロワーとリーダーは ISR と呼ばれ、その他は OSR と呼ばれます。リーダーに障害が発生した場合、ISR のレプリカがランダムに選択されてリーダーになります。ISR に障害が発生した場合、 AR 内の最初のレプリカが選択され、応答のコピーが選択されます。

レプリカのシャーディングルール

Kafka がレプリカを割り当てるには、RangeAssignor と RoundRobinAssignor という 2 つのアルゴリズムがあります。デフォルトは RangeAssignor ですが、シャーディングの場所をカスタマイズすることもできます。

すべてのブローカー (合計 n ブローカーと仮定) と割り当てられるパーティションを並べ替えます。
i 番目のパーティションを (i mod n) 番目のブローカーに割り当てます
i 番目のパーティションの j 番目のレプリカを ((i + j) mod n) 番目のブローカーに割り当てます

Kafka のマルチパーティションおよびマルチレプリカのメカニズムの利点は何ですか?

スループットの向上: マルチパーティションメカニズムにより、メッセージを複数のパーティションで並行して処理できるため、全体的なスループットが向上します。各パーティションは独立したコンシューマ上で同時に処理できるため、システムの並列性と処理能力が向上します。
水平方向のスケーラビリティの実現: Kafka は、データを複数のパーティションに分散することで簡単に水平方向にスケーリングできます。各パーティションを異なるサーバーにデプロイして、負荷分散と水平拡張を実現し、高スループットと大規模なデータ処理のニーズを満たすことができます。
耐障害性の向上: マルチコピーメカニズムにより、各パーティションを複数のレプリカに複製できます。1 つのレプリカに障害が発生した場合、Kafka は読み取りおよび書き込み操作を他の利用可能なレプリカに自動的に切り替えて、高可用性とフォールトトレランスを実現します。さらに、マルチコピー機構によりデータの冗長性も実現され、1 つのコピーが破損した場合でもデータは引き続き利用可能です。
データの永続性の実現: マルチコピーメカニズムにより、データが複数のコピーに複製されることが保証され、それによってデータの永続性が実現されます。1 つのコピーが破損したり誤動作したりした場合でも、他のコピーからデータにアクセスして回復することができます。
メッセージのシーケンスとパーティショニングのサポート: マルチパーティションメカニズムにより、ビジネスニーズに応じてメッセージをさまざまなパーティションに割り当てることができ、各パーティションはメッセージの順序を維持できます。これは、メッセージの順序を保証する必要があるアプリケーションにとって重要です。同時に、パーティションを使用してメッセージをグループ化および分離し、メッセージフローをより適切に制御することもできます。

カフカの動物園飼育員の役割を知っていますか?

コーディネーターの選出: Zookeeper は、Kafka クラスター内のコーディネーター (Coordinator) とコントローラー (Controller) を選出する責任を負います。どちらも 1 つのブローカーによって同時にサービスを提供できます。コントローラーは、Kafka クラスター全体のステータスとメタデータを管理する責任を負い、ロードバランシングを実現するためにさまざまなブローカーにパーティションを割り当てる責任を負います。
構成管理: Kafka のクラスター構成情報 (トピック、パーティション、レプリカなど)、コンシューマーグループのオフセット、その他のメタデータは Zookeeper に保存されます。Kafka の各ブローカーとコンシューマーは、Zookeeper と対話して最新のクラスター構成情報を取得します。
ブローカーの登録と検出: Kafka のブローカーは、起動時にホスト名、ポート番号などの独自の情報を Zookeeper に登録します。同時に、消費者は Zookeeper を通じて利用可能なブローカーノードを発見できます。
パーティションの割り当てと再バランス: 新しいブローカーがクラスターに参加するか、古いブローカーがオフラインになると、Zookeeper はコントローラーによるパーティションの再分散と再バランスを支援します。パーティション割り当て計画を維持し、この情報を各ブローカーに通知して、高いデータ可用性と負荷分散を確保します。
レプリカ管理: Zookeeper は、Kafka パーティションのレプリカ情報を追跡および管理します。レプリカのステータスを監視し、レプリカに障害が発生した場合にはレプリカの再割り当てと回復を行います。
クライアントセッション管理: Kafka コンシューマーとプロデューサーは、Zookeeper を通じてクラスターとのセッション接続を維持します。Zookeeper はクライアントのアクティビティを検出し、接続の失敗と回復を処理できます。

一般に、Zookeeper は、調整、構成管理、パーティション割り当て、コピー管理、クライアントセッション管理など、Kafka で重要な役割を果たし、Kafka クラスターの安定した動作とデータの一貫性を確保します。

カフカはなぜそんなに速いのでしょうか?

分散アーキテクチャ: Kafka は、データと負荷を複数のノードに分散して並列処理とスケーラビリティを実現できる分散アーキテクチャを採用しています。メッセージは複数のパーティションに分割され、各パーティションはクラスター内の異なるノードで処理できるため、水平方向のスケーリングと負荷分散が可能になります。
ゼロコピーテクノロジ: Kafka はゼロコピーテクノロジを使用して、メッセージの読み取りおよび書き込み時に不必要なデータコピー操作を回避します。Kafka は、オペレーティングシステムのファイルマッピング (mmap) メカニズムを使用して、ディスク上のメッセージをメモリに直接マップし、メモリとディスク間のデータコピーのコストを削減し、読み取りおよび書き込みのパフォーマンスを向上させます。
バッチ処理: Kafka はメッセージのバッチ処理をサポートします。プロデューサは複数のメッセージをまとめて Kafka に送信でき、コンシューマは複数のメッセージをバッチで取得して処理することもできます。バッチ処理により、ネットワークのオーバーヘッドとシステムコールの数が削減され、スループットと効率が向上します。
効率的なディスク順次書き込み: Kafka メッセージはランダムに書き込まれるのではなく、ディスクに追加されます。このシーケンシャル書き込み方式により、ディスクの読み取りと書き込みがより効率的になり、シーク時間とディスクの断片化が減少し、ディスクの使用率とパフォーマンスが向上します。最新のオペレーティングシステムは先読みおよび先行書き込みテクノロジを提供しているため、ほとんどの場合、ディスクへのシーケンシャル書き込みはメモリへのランダム書き込みよりも高速です。
メモリベースのストレージとキャッシュ: Kafka は、オペレーティングシステムのページキャッシュを使用してメッセージをキャッシュし、読み取りおよび書き込みのパフォーマンスを向上させます。人気のあるメッセージはメモリにキャッシュされるため、ディスクアクセスの数が減り、メッセージの読み取りが高速化されます。Kafka の書き込み速度がその消費速度と同程度の場合、生成および消費プロセス全体はディスク IO を経由せず、すべてメモリ操作になります。
効率的なレプリケーションメカニズム: Kafka のレプリケーションメカニズムはストリーミングレプリケーションを採用しており、非同期レプリケーションとバッチレプリケーションを通じてレプリケーションの効率とスループットを向上させます。同時に、Kafka は複数のレプリカと ISR (In-Sync Replica) メカニズムも使用して、データの信頼性と高可用性を確保します。

簡単にまとめると、まず、マルチパーティション分散構造はマルチスレッドを最大限に活用します。2 つ目は、オペレーティングシステムのファイルマッピングメカニズムを使用して、ディスクデータをメモリに直接マッピングすることで、1 回限りのコピーのオーバーヘッドを削減し、データの読み取りおよび書き込みのパフォーマンスを向上させることです。3 つ目は、バッチ処理をサポートすることです。バッチ処理は、プロデューサーとコンシューマーの両方によって同時にサポートされ、ネットワークのオーバーヘッドとリクエストの数を削減します。第 4 に、ディスクのシーケンシャル書き込みはランダム書き込みよりも効率的です。5 番目に、ホットニュースはメモリに保存され、読み取りと書き込みのパフォーマンスが向上します。

あまり知られていない知識を共有する

Kafka がページキャッシュを使用せずに独自のキャッシュを管理しないのはなぜですか?

JVM 内のすべてはオブジェクトであり、データをオブジェクトに保存すると、いわゆるオブジェクトのオーバーヘッドと無駄なスペースが発生します。
JVM がキャッシュを管理する場合、キャッシュは GC の影響を受けます。また、ヒープが大きすぎると GC の効率が低下し、スループットが低下します。
プログラムがクラッシュすると、管理しているすべてのキャッシュデータが失われます。

Kafka のパフォーマンス: なぜ Kafka はとても「速い」のでしょうか? [1]、この記事を読んで非常によく書かれていると思ったので、ここに投稿しました。詳しく知りたい方はリンク先へ飛んでご覧ください

Kafka シナリオ分析

Kafka はどのようにして高可用性を確保しますか?

分散アーキテクチャ: Kafka は、複数のブローカーノードにデータを分散して保存する分散アーキテクチャを採用しています。これにより、ブローカーノードに障害が発生した場合でも、他の正常に動作しているブローカーノードが引き続きサービスを提供できます。
マルチコピーメカニズム: Kafka はマルチコピーメカニズムを使用して、データの冗長性と可用性を確保します。各パーティションは、異なるブローカーノードに分散される複数のレプリカで構成できます。レプリカが配置されているブローカーに障害が発生した場合でも、他のレプリカがサービスを引き継ぎ、データの可用性を確保できます。
コントローラー: Kafka クラスター内のコントローラーは、クラスター全体のステータスとメタデータの管理を担当します。ブローカーノードに障害が発生するかオフラインになると、コントローラーはこの変化を検出し、パーティションやレプリカのリーダーシップを再分配するなどの対応する操作を実行して、データの高可用性と一貫性を確保します。
自動障害回復: Kafka には自動障害回復機能があります。ブローカーノードに障害が発生するかオフラインになると、コントローラーはレプリカの再配布および回復プロセスを自動的にトリガーし、レプリカを他の利用可能なブローカーノードに割り当てて、データの冗長性と可用性を確保します。
ハートビートとセッションの有効期限: Kafka とクライアント間の接続はハートビートメカニズムを通じて維持され、クライアントのアクティブステータスが定期的に検出されます。コンシューマーまたはプロデューサーのクライアントが長期間ハートビートを送信しない場合、コントローラーはそのクライアントのセッションが期限切れになったとみなし、そのパーティションを他のアクティブなコンシューマーに再配布します。
監視とアラーム: Kafka は、クラスターのステータス、パーティションの健全性、コンシューマーの進行状況をリアルタイムで監視できる豊富な監視インジケーターとアラームメカニズムを提供します。これにより、潜在的な問題をタイムリーに検出して解決し、システムの可用性と安定性が向上します。

簡単に言うと4つのポイントに分かれます。1つ目はKafkaの分散構造で、複数のパーティションが異なるノードに分散されており、一部のノードがダウンしてもサービスは正常に提供されます。2 番目に、マルチコピーメカニズムにより、データの冗長性による高可用性が保証されます。第三に、Kafka クラスターのコントローラーの役割はクラスター全体のステータスとメタデータを管理し、ノードがオンラインまたはオフラインで監視されると、パーティションとレプリカのリーダーシップが再配分されます。4 つ目は、Kafka クラスターのコーディネーターです。これは、プロダクション側でデータのトランザクション操作を保証し、コンシューマー側でリバランスメカニズムを使用して、データがコンシューマーグループによってスムーズに消費されるようにします。

Kafka はメッセージが繰り返し消費されないようにするにはどうすればよいでしょうか?

Consumer Offset : Kafka は、各コンシューマグループによって消費されるオフセット、つまり処理されたメッセージの位置を維持します。コンシューマーは現在のオフセットを定期的にコミットし、メッセージが正常に消費されたことを示します。Kafka はこのオフセットを保存し、再起動後に復元します。これにより、コンシューマは最後にコミットされたオフセットから消費し続けることができます。
コンシューマグループコーディネーター: Kafka のコンシューマグループコーディネーターは、コンシューマグループのオフセットの追跡と管理を担当します。各コンシューマーのオフセット情報を内部または外部ストレージシステム (Zookeeper や Kafka 独自の内部トピック __consumer_offsets など) に保存します。Kafka は、コーディネーターの管理を通じて、コンシューマグループ内の各コンシューマが最後のオフセットから正しく消費を継続できるようにします。
コンシューマオフセットのコミット: コンシューマは、メッセージのバッチを消費した後にオフセットを手動で送信するか、自動送信設定を通じてオフセットを定期的に自動的に送信するかを選択できます。オフセットを手動でコミットすると、消費が失敗した場合やエラー処理が発生した場合にオフセットがコミットされなくなり、繰り返しの消費が回避されます。自動コミットオフセットは、メッセージを処理する操作が冪等であることを保証するために注意して使用する必要があります。
1 回限りのセマンティクス: Kafka では、トランザクションのプロデューサー API とコンシューマー API を導入し、アプリケーションが「1 回限り」のセマンティクスを実現できるようにします。トランザクションプロデューサーは、Kafka トランザクションにメッセージを書き込み、トランザクションのコミットを確認した後でのみメッセージをコンシューマーに公開できます。トランザクションコンシューマは、オフセットのアトミックな送信と、メッセージ処理後のトランザクション送信を通じてメッセージ処理の一貫性を保証します。

簡単に言うと、Kafka は主にコンシューマーオフセットを使用して、メッセージが繰り返し消費されないようにします。Kafka はコーディネーターと内部 TOPIC (__consumer_offsets) を内部的に使用して、コンシューマーインスタンスが繰り返し消費されないようにします。開発者は、消費オフセットを手動で送信して、消費が失敗した場合や例外が発生した場合にオフセットが送信されないようにして、繰り返しの消費を避けることができます。開発者は、コンシューマ側でべき等な処理を実行することにより、繰り返しの消費を避けることもできます。

Kafka はメッセージが消費される順序をどのように保証しますか?

Kafka は、パーティションおよびパーティション内のオフセットを通じてメッセージの順序を保証します。トピックは複数のパーティションにすることができますが、各パーティションのデータは順次です。プロデューサーによって送信されたメッセージはパーティションの最後に順次追加され、コンシューマーもデータを順次消費します。

つまり、トピックに複数のパーティションがある場合、メッセージの順序はパーティション内でのみ保証され、異なるパーティション間のメッセージの順序は Kafka によって保証されません。アプリケーションのロジックで厳密なグローバル順序付けが必要な場合は、関連するすべてのメッセージを同じパーティションに送信する必要があります。そうでない場合、アプリケーションはコンシューマー側で追加の処理を実行してグローバル順序付けを実現します。

Kafka はどのようにしてメッセージが失われないようにするのでしょうか?

永続ストレージ: Kafka はメッセージをメモリだけでなくディスクに永続的に保存します。各トピックのメッセージは複数のパーティションに書き込まれ、各パーティションは複数のレプリカを持つことができます。このようにして、ブローカーまたはディスクに障害が発生した場合でも、メッセージを他のコピーから回復できるため、メッセージの損失が回避されます。
レプリケーションメカニズム: Kafka はレプリケーションメカニズムを使用して、高可用性とフォールトトレランスを提供します。各パーティションのメッセージを複数のブローカー上で複製して、レプリカセットを形成できます。レプリカセット内の 1 つのレプリカはリーダーとして指定され、読み取りおよび書き込み操作を担当しますが、他のレプリカはフォロワーです。リーダーレプリカに障害が発生すると、フォロワーの 1 つが新しいリーダーとして選出され、メッセージの耐久性と可用性が確保されます。
書き込み確認 (Acknowledgement) : Kafka にメッセージを送信するとき、プロデューサーは、メッセージが正常に書き込まれたことの確認を待つことを選択できます。プロデューサは待機するレプリカの数を構成でき、指定された数のレプリカが正常に書き込まれた後でのみプロデューサは確認を受け取ります。このメカニズムにより、メッセージが十分なレプリカに書き込まれるようになり、メッセージ損失のリスクが軽減されます。
レプリカの同期: Kafka はレプリカ同期メカニズムを使用して、パーティションのレプリカが確実に同期されるようにします。メッセージが書き込まれると、リーダーレプリカはそのメッセージをすべてのフォロワーレプリカにコピーし、その確認応答を待ちます。リーダーレプリカは、すべてのフォロワーレプリカが正常に複製してメッセージを確認した後でのみ、メッセージの書き込みが成功したとみなします。この同期メカニズムにより、データの一貫性が保証され、データ損失の可能性が軽減されます。
コンシューマディスプレイスメントの送信: コンシューマはメッセージを消費するときに、消費されたディスプレイスメント (オフセット) を定期的に Kafka に送信します。このようにして、コンシューマが失敗した場合やコンシューマグループに再参加した場合でも、最後に送信されたディスプレイスメントに基づいて消費を再開できます。オフセット送信を通じて、Kafka はコンシューマーの進行状況を追跡し、メッセージが 2 回消費されたり失われたりしないようにできます。

簡単に要約すると、Kafka のマルチコピー冗長データメカニズムは、複数のノード上の複数のバックアップで使用できます。また、ACK メカニズムは、トランザクションメカニズムと同様に、プロデューサがメッセージを送信した後、終了リクエストを確認する前に一部またはすべてのレプリカがメッセージを受信することを選択できることを保証します。コンシューマは、オフセットを積極的に送信することで、メッセージの繰り返しの消費や損失を回避することもできます。

メッセージのバックログに対処する方法

コンシューマの処理能力を向上させる: コンシューマインスタンスの数を増やすことで、コンシューマの同時処理能力を高めることができます。これにより、メッセージがより速く消費され、バックログが削減されます。
コンシューマの処理ロジックを調整する: コンシューマの処理ロジックが複雑な場合、処理速度が遅くなる可能性があります。コンシューマのコードロジックを評価および最適化して、処理効率を向上させることができます。
パーティションの数を増やす: トピックのパーティションの数を増やすと、メッセージの並列性が向上します。このようにして、各パーティション内のメッセージが異なるコンシューマインスタンスに均等に分散されるため、バックログの問題が軽減されます。
プロデューサの送信レートを調整する: プロデューサの送信レートが速すぎるためにメッセージスクイーズが発生している場合は、コンシューマがメッセージを処理するのに十分な時間を確保できるように、プロデューサの送信レートを調整してメッセージ生成レートを下げることができます。
Kafka クラスターのリソースを増やす: Kafka クラスターのリソース (ディスク、ネットワーク帯域幅など) が不十分な場合、メッセージ処理が遅くなる可能性があります。全体的な処理能力を向上させるために、クラスターのリソースを増やすことを検討してください。

簡単にまとめると、通常の状況では消費圧力が高く、一時的に流通エリアと消費者数を拡大することで消費速度を高めることができます。私自身の経験に基づくフォローアップですが、メッセージバックログの問題を解決するのは難しいですか? このアイデアのコード最適化の詳細は完全に公開されており [2]、プロジェクトの困難さがまとめられています。

カフカのソースコード

制作側

NIO ネットワーク通信モジュール: Kafka が Java NIO に基づいた一連の工業生産グレードのネットワーク基盤となる通信モジュールを実装する方法

メモリバッファプールの設計: Kafka クライアントが数百万の同時実行をサポートする高スループットのバッファリングメカニズムを設計する方法

送信側スレッド: 重要な点は、Kafka クライアントがネットワーク通信を通じてメッセージのバッチを Kafka ブローカーにどのように送信するかということです。これには、ネットワーク通信、いくつかのパラメータ設定、およびネットワーク障害の処理に関する多くの詳細が含まれます。

クラスターのメタデータのプルと更新のメカニズム: クラスターのメタデータのプルコンポーネントとプルのタイミング、メタデータがクライアントにキャッシュされる方法、きめ細かいオンデマンドの読み込みとトピックメタデータの同期待機をサポートする方法。

サーバ

クラスターアーキテクチャ: Kafka ブローカーのクラスターアーキテクチャがどのように実装されるか、各ブローカーが起動後にクラスターを形成する方法、クラスターコントローラーがどのように選択されるか、障害回復高可用性アーキテクチャがどのように実装されるかなど。

サーバー側ネットワーク通信モジュール: Kafka サーバー側ネットワーク通信モジュールの実装方法、Reactor 設計モデルと超高同時実行性をサポートする Kafka の Reactor ベースのネットワークアーキテクチャの理解、アクセプタースレッド、プロセッサスレッド、 RequestChannel、IO スレッドプール、およびその他のネットワーク基礎となる通信コンポーネントの実装とリクエスト処理プロセス全体のソースコード。

パーティションとレプリカ: マルチコピー冗長性と高可用性アーキテクチャを実装する方法、リーダーとフォロワーのデータがどのように同期されるか、レプリカが送信される方法、およびそれらの間の HW と LEO がどのように変更されるか、リーダーの後にシステムの高可用性を確保する方法ブローカーが失敗してダウンする、レプリカマネージャーがレプリカを管理する方法、ブローカーがメタデータキャッシュを非同期で更新する方法など。

ロードバランシングとスケーリングアーキテクチャ: データがクラスターのブローカーマシンに均等に分散されるようにする方法、トピックとブローカーのパーティションをスケーリングする方法。

ログストレージアーキテクチャ: Kafka が効率的に保存する方法、ディスクの読み取りと書き込みがどのように実装されるか、ログのストレージ構造とは何か、OS キャッシュ、ゼロコピー、スパースインデックス、シーケンシャル書き込み、および超高スループットストレージをサポートするその他の優れた設計を使用する方法建築。

消費者側

消費プロセス: コンシューマの初期化方法、サーバーとの通信方法、コンシューマのpoll()メソッドがデータを消費する方法。

コンシューマグループ管理: コンシューマグループの概念、ステートマシンフロー、コンシューマが起動後にグループに参加する方法、コンシューマグループ管理の全プロセス、コンシューマグループのメタデータ管理の設計原則など。

コーディネーターのメカニズム: コンシューマーコーディネーターの仕組み、コンシューマーコーディネーターがコンシューマーリーダーを選出する方法、コンシューマーリーダーがパーティション割り当て計画を策定する方法、コンシューマーコーディネーターがパーティション割り当て計画を発行する方法、コンシューマーがコンシューマーコーディネーターにハートビートを定期的に送信する方法、など待ってください。

メッセージリバランスメカニズム: いくつかのリバランスシナリオ、およびリバランスソースコードプロセス分析。

__consumer_offsets : トピック内のトピック。

サブスクリプションステータスとオフセット操作: コンシューマのサブスクリプションステータスがトピックパーティションとオフセットの間の対応関係をどのように保存および追跡するか、オフセットの取得および送信方法などを理解します。

メッセージキューを設計するにはどうすればよいですか?

メッセージキューを設計するときは、次の重要な側面を考慮できます。

要件と目的の定義: メッセージキューの目的、予想されるスループット、遅延要件、データサイズ制限、その他の要件を明確にします。解決しようとしている問題と達成したい目標を理解することは、適切な設計の方向性を決定するのに役立ちます。
適切なメッセージキューミドルウェアを選択する: ニーズと使用法に基づいて、適切なメッセージキューミドルウェアを選択します。Kafka、RabbitMQ、ActiveMQ など、多くのオープンソースおよび商用メッセージキューミドルウェアから選択できます。機能、信頼性、パフォーマンス、拡張性、コミュニティサポートなどの側面を考慮してください。
メッセージ形式とプロトコルを定義する: メッセージ構造、データフィールド、および考えられるメッセージヘッダーとメタデータを含むメッセージ形式とプロトコルを設計します。これはメッセージの一貫性とスケーラビリティに役立ち、消費者に有益な情報を提供します。
メッセージの永続性と信頼性を考慮する: メッセージの損失を防ぐためにメッセージをディスクに永続化する必要があるかどうかを判断します。一部のメッセージキューミドルウェアには、障害が発生した場合でもメッセージが失われないようにするための永続化オプションが用意されています。
メッセージの順序を考慮する: アプリケーションにとってメッセージの順序が重要である場合は、順序付けされたメッセージ配信をサポートするメッセージキューミドルウェアを選択し、ニーズに応じて適切なメッセージパーティショニングと順序保証メカニズムを設計する必要があります。
メッセージの分割とスケーリングを検討する: 大量のメッセージと高いスループットが予想される場合は、メッセージの分割とスケーリングの方法を検討する必要があります。これにより、システムの並列性とスケーラビリティが向上し、メッセージが効率的に処理されるようになります。
適切なセキュリティメカニズムを実装する: 認証、アクセス制御、データ暗号化などを含むメッセージセキュリティを考慮します。メッセージの機密性と完全性を保護するためのニーズに基づいて、適切なセキュリティメカニズムを選択します。
監視と管理: メッセージキューのパフォーマンス、スループット、待ち時間、その他の指標をリアルタイムで監視できるように、監視と管理のメカニズムを設計します。これは、問題を迅速に特定してトラブルシューティングするのに役立ちます。

メッセージキューを設計するには、複数の要素を包括的に考慮し、実際のニーズとアプリケーションシナリオに基づいて決定を下す必要があります。これらのガイドラインは、信頼性が高く、パフォーマンスが高く、スケーラブルなメッセージキューシステムの設計を開始するのに役立ちます。

読みました、前回の記事は6月27日、この記事は7月23日、ざっくり書いたのは21日、ずっといじって月曜に初投稿しました。 1月。この更新頻度は確かに少し遅いですが、今後も時間をかけて取り組んでいきます。ブロガーさん、ほぼ一ヶ月が経ちました（笑）色々なことがありましたが、平凡だった先週を除けば、残りの二週間は私にとって興奮と驚きの連続でした。私自身、新たな目標とモチベーションが湧いてきました。今後は仕事、生活、勉強を両立させていきます。この世界はとても面白いです。本気です。

私は怠け者です。正直に言うと、ここ数週間は勉強する時間が十分ではありませんでした。仕事と生活にもっと集中してきました。先週は残業もしてしまい、とても迷惑でした。「人生の面では、もしかしたら私のメンタリティがまた変わったのかもしれません。なぜ最近なのかわかりませんが、インスピレーションを与える言葉をたくさん読んだり、これまであえてしなかったようなことをするようになりました。それはとても大胆で、真剣です」結果はかなり良くて、とにかくとても幸せです（笑）、素晴らしい気分です、私の精神がより前向きになったように感じます。結果はどうであれ、自分の意志に逆らわずにもっと頑張ってやるよ、さあ！私の人生信条を改めて申し上げます。この苦しくて息苦しい世界に幸せの花を咲かせ、この美しい世界に祝福を捧げます！！

参考文献

[1]

https://mp.weixin.qq.com/s/kMIhPW2uLdy-mgS9sF6agw: https://link.juejin.cn/?target=https%3A%2F%2Fmp.weixin.qq.com%2Fs%2FkMIhPW2uLdy-mgS9sF6agw

[2]

https://juejin.cn/post/7209657931124555834: https://juejin.cn/post/7209657931124555834