わずか3分でKafkaの仕組みを理解できます

週末、退屈で携帯電話を閲覧していたところ、Taobao アプリに突然「昔の顧客への恩返しとして、ガールフレンドは今日だけ、1 つ買うと 1 つ無料という特典を利用できます!」というメッセージが表示されました。

1 つ買うと 1 つ無料というお得なセールがあるので、見逃せません!思わずすぐにクリックしてしまいました。そこで、2つのモデルを選択し、注文して、一度に支払いました。もうすぐ彼女ができるんだと満足してベッドに横たわっていたら、嬉しくて眠れなくなってしまいました…

翌日、いつものように仕事をしていたところ、突然宅配業者から電話がかかってきた。

若い男性: 「あなたはxxですか? 彼女がここにいます。私は今階下にいるから、迎えに来てください!」

私：「えっと…今仕事中なので、夕方に届けてもらえますか？」

若者：「夜はダメですよ。僕も夜は仕事が休みなんです！」

それで二人は長い間膠着状態にあったのですが...

***その男性は、「小芳コンビニの階下に置いておくから、夕方仕事が終わったら取りに来てくれませんか」と言いました。気まずい状況がようやく解消されました！

メッセージ キューはなぜ必要なのでしょうか?

話を元に戻すと、小芳コンビニがなければ、宅配業者と私の間の相互作用図は次のようになるはずです。

何が起こるでしょうか?

• 彼女のために、休暇を取って戻って取りに行きました（上司は許可しませんでした）。
• その人は階下であなたを待っています（他の速達配達もあるので）。
• 週末に再度配送します (もちろん待ちきれません)。
• もうこの彼女は要らない（絶対無理）！

Xiaofang Convenience Store が表示された後、インタラクティブな図は次のようになります。

上記の例では、「配達人」と「ガールフレンドを買う私」は相互作用する必要がある 2 つのシステムであり、Xiaofang Convenience Store がこの記事で説明するメッセージ ミドルウェアです。

まとめると、小芳コンビニエンスストア（メッセージミドルウェア）の登場には次のような利点があります。

デカップリング

宅配便の配達員は速達の荷物をたくさん持っています。そのたびに、各受取人に電話して、配達可能かどうか、いつ配達可能かを確認し、配達計画を決定する必要があります。これは完全に荷受人次第です!配達員が多すぎると、配達員はおそらく非常に忙しくなります...

コンビニエンスストアがある場合、宅配業者は、同じコミュニティ内の同じコンビニエンスストアに荷物を置き、受取人に商品を受け取るよう通知するだけで済みます。この時点で、配達人と荷受人は切り離されます。

非同期

宅配業者が私に電話した後、他の人の荷物を配達する前に、私があなたの荷物を受け取るまで、宅配業者は階下で待機する必要があります。

宅配業者は小坊コンビニエンスストアに荷物を置いた後、他の仕事に行くことができます。あなたが到着するまで待つ必要がなくなり、仕事の効率が向上します。

ピークシェービング

たとえば、ダブルイレブンでさまざまな店舗からさまざまな商品を購入したとします。これらの店舗の速達便は、中通、元通、神通、さまざまな速達便など、それぞれ異なっていました。しかも、すべて同時に届きました。

ZTO の担当者が私に電話をかけてきて、エクスプレスを受け取るために北ゲートに行くように指示し、YTO の担当者は南ゲートに行くように指示し、STO の担当者は東ゲートに行くように指示しました。急いでいたので…

システムが相互作用する必要があるシナリオでは、メッセージ キュー ミドルウェアを使用すると多くの利点があることがわかります。この考えに基づいて、小芳コンビニエンスストアよりも、鳳潮や菜鳥駅などの専門的な「ミドルウェア」が多く存在します。

***、上記の物語は完全にフィクションです...

メッセージキュー通信モード

上記の例を通じて、メッセージ ミドルウェアとメッセージ キューの利点を紹介しました。ここでは、メッセージ キュー通信の 2 つのモードを導入する必要があります。

ポイントツーポイントモード

上の図に示すように、ポイントツーポイント モードは通常、プルまたはポーリング メッセージング モデルに基づいており、キューに送信されたメッセージが 1 つのコンシューマーのみによって処理されるという特徴があります。

プロデューサーがメッセージをメッセージ キューに入れると、コンシューマーはメッセージを積極的にプルして消費します。ポイントツーポイント モデルの利点は、コンシューマーがメッセージをプルする頻度を自分で制御できることです。

ただし、コンシューマー側では、メッセージ キューに消費する必要があるメッセージがあるかどうかを認識できないため、コンシューマー側でそれを監視するための追加のスレッドが必要になります。

パブリッシュ・サブスクライブモデル

上図に示すように、パブリッシュ サブスクライブ モデルは、複数の異なるサブスクライバーを持つことができるメッセージ送信に基づくメッセージ伝送モデルです。

プロデューサーがメッセージをメッセージ キューに入れると、キューはこのタイプのメッセージをサブスクライブしているコンシューマーにメッセージをプッシュします (WeChat パブリック アカウントと同様)。

コンシューマーはプッシュ メッセージを受動的に受信するため、メッセージ キューに消費するメッセージがあるかどうかを感知する必要はありません。ただし、コンシューマー 1、コンシューマー 2、およびコンシューマー 3 のマシン パフォーマンスは異なるため、メッセージを処理する能力も異なりますが、メッセージ キューはコンシューマーの消費速度を感知できません。

したがって、プッシュ速度はパブリッシュ/サブスクライブ モデルの問題になります。 3 つのコンシューマーの処理速度がそれぞれ 8M/s、5M/s、2M/s であると仮定すると、キューのプッシュ速度が 5M/s の場合、Consumer3 はそれに耐えられません。

キューのプッシュ速度が 2M/s の場合、Consumer1 と Consumer2 は大量のリソースを浪費します。

カフカ

上記では、メッセージ キューが必要な理由と、メッセージ キュー通信の 2 つのモードについて簡単に説明しました。いよいよ今回の主人公、カフカが華々しくデビューします！

Kafka は、消費者規模の Web サイトのすべてのアクション ストリーム データを処理できる、高スループットの分散型パブリッシュ/サブスクライブ メッセージング システムです。高いパフォーマンス、永続性、マルチコピーバックアップ、水平スケーラビリティを備えています。

インフラストラクチャと用語

さっそく、写真を見てみましょう。この図を通して、関連する概念とそれらの関係を整理することができます。

この写真を見て混乱したとしても、それは問題ではありません！まず関連する概念を分析してみましょう。

• プロデューサー: プロデューサーは、メッセージのプロデューサー、ジェネレーター、およびメッセージのエントリ ポイントです。
• Kafka クラスター:

ブローカー: ブローカーは Kafka インスタンスです。各サーバーには 1 つ以上の Kafka インスタンスがあります。各ブローカーは 1 つのサーバーに対応すると想定します。

Kafka クラスター内の各ブローカーには、図の Broker-0、Broker-1 などの一意の番号があります...

トピック: メッセージの主題。メッセージの分類として理解できます。 Kafka データはトピックに保存されます。各ブローカーには複数のトピックを作成できます。

パーティション: トピック パーティション。各トピックには複数のパーティションを含めることができます。パーティションの役割は、負荷を処理し、Kafka のスループットを向上させることです。

異なるパーティション内の同じトピックのデータは重複せず、パーティションはフォルダーごとに 1 つずつ表されます。

レプリケーション: 各パーティションには複数のレプリカがあり、バックアップとして機能します。プライマリ パーティション (リーダー) に障害が発生すると、バックアップ パーティション (フォロワー) が選択され、引き継いでリーダーになります。

Kafka では、レプリカのデフォルトの最大数は 10 であり、レプリカの数はブローカーの数より大きくすることはできません。フォロワーとリーダーは必ず異なるマシン上に存在し、同じマシンには同じパーティションのレプリカを 1 つだけ (そのマシン自体を含む) 保存できます。

• メッセージ: 送信された各メッセージの本文。
• コンシューマー: コンシューマーはメッセージの消費者であり、メッセージの出口です。
• コンシューマー グループ: 複数のコンシューマー グループを 1 つのコンシューマー グループに結合できます。 Kafka の設計では、同じパーティション内のデータは、コンシューマー グループ内の 1 つのコンシューマーのみが使用できます。

同じコンシューマー グループ内のコンシューマーは、同じトピックの異なるパーティションからデータを消費できるため、Kafka のスループットも向上します。

• Zookeeper: Kafka クラスターは、システムの可用性を確保するために、クラスターのメタデータを保存するために Zookeeper に依存しています。

ワークフロー分析

上記では、Kafka の基本的なアーキテクチャと基本的な概念を紹介しました。読んでみて、カフカについての全体的な印象はありましたか。まだ混乱していても問題ありません!

次に、上記の構造図と組み合わせて、Kafka のワークフローを分析します。戻ってもう一度見直すと、より多くのことが得られると思います。

データの送信

上記のアーキテクチャ図を見ると、Producer はプロデューサーであり、データのエントリ ポイントです。図の赤い矢印に注意してください。データを書き込むとき、プロデューサーは常にリーダーを探し、フォロワーに直接データを書き込むことはありません。

では、リーダーをどうやって見つけるのでしょうか?執筆プロセスはどのようなものですか?次の図を見てみましょう。

送信手順は図で説明してあるので、テキストでは別途記載しません！注目すべき点は、メッセージがリーダーに書き込まれた後、フォロワーが同期のために積極的にリーダーに移動するということです。

プロデューサーはプッシュ モードを使用してブローカーにデータを公開します。各メッセージはパーティションに追加され、ディスクに順番に書き込まれるため、同じパーティション内のデータの順序が保証されます。

書き方の図は次のようになります。

前述のように、データは異なるパーティションに書き込まれます。では、なぜ Kafka にパーティショニングが必要なのでしょうか?パーティション分割の主な目的は次の通りだと推測できると思います。

• 拡張も簡単。トピックは複数のパーティションを持つことができるため、マシンを拡張することで増加するデータ量に簡単に対応できます。
• 同時実行性を向上させます。パーティションを読み取りおよび書き込み単位として使用すると、複数のコンシューマーが同時にデータを消費できるため、メッセージ処理の効率が向上します。

負荷分散に詳しい人なら、サーバーにリクエストを送信すると、サーバーがリクエストを読み込み、トラフィックを別のサーバーに分散する可能性があることを知っているはずです。

では、Kafka では、トピックに複数のパーティションがある場合、プロデューサーはどのパーティションにデータを送信するかをどのように知るのでしょうか?

Kafka にはいくつかの原則があります。

• パーティション 書き込み時に、書き込むパーティションを指定できます。指定すると、対応するパーティションが書き込まれます。
• パーティションが指定されていないが、データのキーが設定されている場合、パーティションはキー値に基づいてハッシュされます。
• パーティションもキーも設定されていない場合は、ポーリングによってパーティションが選択されます。

メッセージが失われないようにすることは、メッセージ キュー ミドルウェアの基本的な保証です。では、プロデューサーはどのようにして、Kafka にメッセージを書き込むときにメッセージが失われないようにできるのでしょうか?

実際、それは上記の書き込みフローチャート、つまり ACK 応答メカニズムを通じて説明されています。プロデューサーがキューにデータを書き込むときに、Kafka がデータを受信したことを確認するかどうかを決定するパラメータを設定できます。このパラメータに設定できる値は0、1、およびすべてです。

• 0 は、プロデューサーがクラスターにデータを送信するときにクラスターが戻るのを待つ必要がなく、メッセージが正常に送信されたことを保証しないことを意味します。安全第一、しかし効率第一。
• 1 は、プロデューサーがクラスターにデータを送信するときに、リーダーが応答する限り次のピースを送信でき、リーダーがデータを正常に送信することを保証することを意味します。
• all は、プロデューサーがクラスターにデータを送信するときに、すべてのフォロワーが次のデータを送信する前にリーダーからの同期を完了する必要があり、リーダーがデータを正常に送信し、すべてのレプリカがバックアップされることを保証することを意味します。安全第一、しかし効率第一。

***存在しないトピックにデータを書き込む場合、正常に書き込めるかどうかに注意してください。 Kafka はトピックを自動的に作成し、デフォルトの構成ではパーティションとレプリカの数は 1 になります。

データを保存

プロデューサーがデータを Kafka に書き込んだ後、クラスターはデータを保存する必要があります。 Kafka はデータをディスクに保存します。一般的に、ディスクへの書き込みは時間のかかる操作であり、このような高同時実行コンポーネントには適していないと考えられています。

Kafka は最初に別のディスク領域を割り当て、データを順番に書き込みます (ランダム書き込みよりも効率的です)。

①パーティション構造

前述したように、各トピックは 1 つ以上のパーティションに分割できます。トピックがより抽象的だと思うなら、パーティションはより具体的です。

パーティションはサーバー上で 1 つずつフォルダーとして表され、各パーティション フォルダーには複数のセグメント ファイルのグループがあります。

セグメント ファイルの各セットには、.index ファイル、.log ファイル、.timeindex ファイル (以前のバージョンでは使用できません) の 3 つのファイルが含まれています。

ログ ファイルはメッセージが実際に保存される場所であり、インデックス ファイルと Timeindex ファイルはメッセージを取得するために使用されるインデックス ファイルです。

上記のように、このパーティションには 3 つのセグメント ファイル グループがあります。各ログ ファイルのサイズは同じですが、保存されるメッセージの数は必ずしも同じではありません (各メッセージのサイズは一貫していません)。

ファイルはセグメントの最小オフセットに基づいて名前が付けられます。たとえば、000.index は、オフセットが 0 から 368795 のメッセージを格納します。Kafka は、セグメンテーション + インデックスを使用して、検索効率の問題を解決します。

②メッセージ構造

上記のログ ファイルは、実際にメッセージが保存される場所です。プロデューサーから Kafka にメッセージを 1 つずつ書き込みます。

ログに保存されるメッセージはどのようなものですか?メッセージには主に、メッセージ本文、メッセージ サイズ、オフセット、圧縮タイプなどが含まれます。

知っておくべき 3 つの重要なポイントは次のとおりです。

• オフセット: オフセットは、パーティション内の各メッセージの位置を一意に決定できる 8 バイトの連続 ID 番号です。
• メッセージ サイズ: メッセージ サイズは 4 バイトを占め、メッセージのサイズを記述するために使用されます。
• メッセージ本文: メッセージ本文には実際のメッセージ データ (圧縮済み) が格納され、占有されるスペースは特定のメッセージによって異なります。

③ ストレージ戦略

Kafka は、メッセージが消費されたかどうかに関係なく、すべてのメッセージを保存します。では、古いデータを削除する戦略は何でしょうか?

• 時間ベースで、デフォルト設定は 168 時間 (7 日間) です。
• サイズに基づいて、デフォルトの構成は 1073741824 です。

Kafka が特定のメッセージを読み取る時間の計算量は O(1) であるため、ここで期限切れのファイルを削除しても Kafka のパフォーマンスは向上しないことに注意してください。

消費データ

メッセージがログ ファイルに保存されると、コンシューマーはそれを使用できるようになります。メッセージ キュー通信の 2 つのモードについて説明する際に、ポイントツーポイント モードとパブリッシュ サブスクライブ モードについて説明しました。

Kafka はポイントツーポイント モデルを使用します。コンシューマーは Kafka クラスターからメッセージをアクティブにプルします。プロデューサーと同様に、コンシューマーもメッセージをプルするときにリーダーを探します。

複数のコンシューマーがコンシューマー グループ (コンシューマー グループ) を形成でき、各コンシューマー グループにはグループ ID があります。

同じコンシューマー グループ内のコンシューマーは、同じトピックの下にある異なるパーティションからデータを消費できますが、グループ内の複数のコンシューマーは同じパーティションからデータを消費しません。

ちょっとわかりにくいですか？次の図を見てみましょう。

この図は、コンシューマー グループ内のコンシューマーの数がパーティションの数よりも少ない状況を示しています。そのため、コンシューマーが複数のパーティションからデータを消費する状況が発生し、消費速度は 1 つのパーティションのみを処理するコンシューマーの処理速度ほど速くありません。

コンシューマー グループ内のコンシューマーの数がパーティションの数より多い場合、同じパーティションのデータを消費するコンシューマーが複数存在することになりますか?

前述の通り、このような状況は発生しません!追加のコンシューマーはどのパーティションからもデータを消費しません。

したがって、実際のアプリケーションでは、コンシューマー グループ内のコンシューマーの数をパーティションの数と一致させることが推奨されます。

データの保存に関するセクションでは、パーティションが複数のセグメントに分割される方法について説明しました。各セグメントには、.log、.index、.timeindex ファイルが含まれています。保存される各メッセージには、オフセット、メッセージ サイズ、メッセージ本文などが含まれます。

セグメントとオフセットについては何度も言及しました。 Segment+Offset を使用してメッセージを検索するにはどうすればよいですか?

オフセットが 368801 のメッセージを検索する必要がある場合のプロセスは何ですか?次の図を見てみましょう。

① まず、オフセット 368801 メッセージが配置されているセグメント ファイルを検索します (バイナリ検索を使用)。ここで見つかったファイルは 2 番目のセグメント ファイルです。

②見つかったセグメント内の.indexファイル（つまり、368796.indexファイル、このファイルの開始オフセットは368796+1）を開きます。

探しているオフセット 368801 のメッセージは、インデックス内のオフセットが 368796+5=368801 であるため、ここで検索する相対オフセットは 5 です。

ファイルは、相対オフセットと対応するメッセージの物理オフセットの関係を格納するためにスパース インデックスを使用するため、相対オフセットが 5 のインデックスを直接見つけることはできません。

ここで、バイナリ検索は、指定された相対オフセット以下の相対オフセットを持つインデックス エントリを見つけるためにも使用されます。したがって、相対オフセットが 4 のインデックスが見つかります。

③ 相対オフセット4が見つかったインデックスに従って、メッセージストレージの物理オフセット位置を256と決定します。

データ ファイルを開き、オフセットが 368801 のメッセージが見つかるまで、位置 256 から順番にスキャンします。

このメカニズムは、オフセットが順序付けられていることに基づいており、セグメント + 順序付けられたオフセット + スパース インデックス + バイナリ検索 + シーケンシャル検索などの複数の方法を使用して、効率的にデータを検索します。

この時点で、消費者は処理のために処理する必要があるデータを取得できます。では、各消費者は消費場所をどのように記録するのでしょうか?

初期のバージョンでは、コンシューマーは消費したオフセットを Zookeeper で管理し、一定期間ごとにそれらを報告していたため、繰り返し消費され、パフォーマンスが低下するという問題がありました。

新しいバージョンでは、コンシューマーによって消費されたオフセットが、Kafka クラスターの __consumer_offsets トピックで直接管理されるようになりました。

著者: 蘇静

紹介: 彼は、大規模なインターネット プロジェクトの開発において長年の経験があり、高同時実行性、分散性、マイクロサービス テクノロジーに関する詳細な研究と関連する実践経験を持っています。私は独学で、テクノロジーの研究と共有に熱心に取り組んでいます。私のモットー: 常に学ぶ心を持ち続けること!