はじめる！ Kafka を分かりやすく紹介しましょう。

[[315603]]

序文「私は、パンデミック中にゲームをプレイしながら Kafka を学びました。ActiveMQ や RabbitMQ を使用したことはありますが、Kafka 技術に関しては初心者でもあります。記事に不完全な点や不正確な点がありましたら、ご指摘ください。」今日は、主に Kafka を再理解し、Kafka のより重要な概念と問題について話すために、Kafka についてお話します。次の記事で紹介します:

ワークフローなどの Kafka の高度な機能の一部。
Docker を使用して Kafka をインストールし、それを使用してメッセージを送信および消費します。
Spring Boot プログラムで Kafka をメッセージキューとして使用する方法。

Kafka についてよく言及する場合、それは優れたメッセージキューであると想定されます。 RocketMQ や RabbitMQ と比較されることもよくあります。他のメッセージキューと比較した Kafka の主な利点は次のとおりだと思います。

極めて高いパフォーマンス: Scala および Java 言語に基づいて開発されたこの設計では、バッチ処理と非同期のアイデアを広範に活用し、1 秒あたり数千万のメッセージを処理できます。
比類のないエコシステムの互換性: Kafka と周囲のエコシステムとの互換性は、特にビッグデータとストリームコンピューティングの分野で最高レベルです。

実際、初期の頃、Kafka は適切なメッセージキューではありませんでした。メッセージキューの分野では、初期の Kafka は機能が不完全で、メッセージの損失やメッセージの信頼性の保証の失敗などのいくつかの小さな問題を抱えた、ぼろぼろの子供のようでした。もちろん、これは LinkedIn が最初に大量のログを処理するために Kafka を開発したという事実とも密接に関係しています。ハハハハ、もともとメッセージキューとして意図されていたわけではありませんが、誤ってメッセージキューフィールドの場所を占有することになるとは誰が想像したでしょうか。

その後の開発で、これらの欠点は Kafka によって徐々に修正され、改善されました。したがって、**、Kafka はメッセージキューとして信頼できないという主張は時代遅れです!**

Kafkaを使い始める

まずは最も権威があり、リアルタイムであるはずの公式サイトの紹介を見てみましょう。英語であっても問題ありません。より重要な情報を抜粋しました。

公式紹介から、次の情報を得ることができます。

Kafka は分散ストリーム処理プラットフォームです。これはどういう意味ですか？

ストリーミングプラットフォームには、次の 3 つの主要な機能があります。

メッセージキュー: メッセージストリームを公開およびサブスクライブします。この機能はメッセージキューに似ているため、Kafka もメッセージキューとして分類されます。
記録されたメッセージストリームのフォールトトレラントな永続ストレージ: Kafka はメッセージをディスクに永続化することで、メッセージ損失のリスクを効果的に回避します。
ストリーム処理プラットフォーム: Kafka は、メッセージが公開されたときにそれを処理するための完全なストリーム処理ライブラリを提供します。

Kafka には主に 2 つのアプリケーションシナリオがあります。

メッセージキューイング: システムまたはアプリケーション間でデータを確実に取得するためのリアルタイムストリーミングデータパイプラインを構築します。
データ処理: データストリームを変換または処理するためのリアルタイムストリーミングデータ処理プログラムを構築します。

Kafka に関するいくつかの非常に重要な概念:

Kafka はレコードのストリーム (ストリーミングデータ) をトピックに保存します。
各レコードは、キー、値、タイムスタンプで構成されます。

Kafka メッセージモデル

「余談ですが、初期の JMS と AMQP は、メッセージサービスの分野で権威ある組織によって開発された標準でした。JavaGuide の記事「メッセージキューは実際には非常にシンプル」で紹介しました。ただし、これらの標準の進化はメッセージキューの進化に追いつくことができず、これらの標準は実際には放棄された状態になっています。そのため、異なるメッセージキューには独自のメッセージモデルが存在する可能性があります。

「キューモデル: 初期のメッセージモデル

プロデューサーとコンシューマーのモデルを満たすために、キューをメッセージ通信キャリアとして使用します。メッセージは 1 つのコンシューマーのみが使用でき、消費されなかったメッセージは消費されるかタイムアウトになるまでキューに保持されます。たとえば、プロデューサーが 100 件のメッセージを送信し、2 人のコンシューマーが消費する場合、通常、2 人のコンシューマーは、メッセージが送信された順序でメッセージの半分を消費します (つまり、あなたが 1 つ消費し、私が 1 つ消費します)。

キューモデルの問題

プロデューサーによって生成されたメッセージを複数のコンシューマーに配布する必要があり、各コンシューマーが完成したメッセージコンテンツを受信できる状況があるとします。

この場合、キューモデルを解くのは困難です。議論好きな人の多くは、次のように言います。「消費者ごとに個別のキューを作成し、プロデューサーが複数のコピーを送信できるようにすることができます。」これは非常に愚かな習慣です。リソースを浪費するだけでなく、メッセージキューを使用する目的も失われます。

パブリッシュ・サブスクライブモデル: Kafka メッセージモデル

パブリッシュ/サブスクライブモデルは、主にキューモデルに存在する問題を解決するために設計されています。

パブリッシュサブスクライブモデル (Pub-Sub) は、トピックをメッセージ通信キャリアとして使用します。これはブロードキャストモデルに似ています。パブリッシャーはメッセージをパブリッシュし、そのメッセージはトピックを通じてすべてのサブスクライバーに配信されます。メッセージがブロードキャストされた後にサブスクライブしたユーザーは、メッセージを受信しません。

パブリッシュサブスクライブモデルでは、サブスクライバーが 1 つだけの場合は、基本的にキューモデルと同じです。したがって、パブリッシュ/サブスクライブモデルは機能レベルでキューモデルと互換性があります。

Kafka はパブリッシュ/サブスクライブモデルを使用します。次の図に示すように:

「RocketMQ のメッセージモデルは基本的に Kafka と同じです。唯一の違いは、RocketMQ にはキューの概念がなく、パーティションの概念があることです。

「カフカの重要な概念の解釈

Kafka はプロデューサーによって公開されたメッセージをトピックに送信し、これらのメッセージを必要とするコンシューマーは、次の図に示すように、これらのトピックをサブスクライブできます。

Kafka トピックパーティション

上の図では、Kafka のいくつかの重要な概念も紹介されています。

プロデューサー: メッセージを生成する当事者。
コンシューマー: メッセージを消費する側。
ブローカー: 独立した Kafka インスタンスと見なすことができます。複数の Kafka ブローカーが Kafka クラスターを形成します。

同時に、各ブローカーにはトピックとパーティションという 2 つの重要な概念が含まれていることに気づいたはずです。

トピック: プロデューサーは特定のトピックにメッセージを送信し、コンシューマーは特定のトピックをサブスクライブしてメッセージを消費します。
パーティション: パーティションはトピックの一部です。トピックには複数のパーティションを含めることができ、同じトピックのパーティションは異なるブローカーに分散できます。つまり、トピックは複数のブローカーにまたがることができます。これはまさに私が上で描いた絵の通りです。

「重要な点: Kafka のパーティションは、実際にはメッセージキューのキューに対応します。これは理解しやすいでしょうか?」

さらに、より重要だと思うもう 1 つの点は、Kafka がパーティション (Partion) のマルチコピー (Replica) メカニズムを導入していることです。パーティション内の複数のレプリカの中には、リーダーと呼ばれるものがあり、その他のレプリカはフォロワーと呼ばれます。送信したメッセージはリーダーコピーに送信され、フォロワーコピーは同期のためにリーダーコピーからメッセージをプルできます。

「プロデューサーとコンシューマーは、リーダーレプリカとのみ対話します。他のレプリカはリーダーレプリカのコピーと考えることができます。これらは、メッセージストレージのセキュリティを確保するためだけに存在します。リーダーレプリカに障害が発生すると、フォロワーからリーダーが選出されますが、いずれかのフォロワーがリーダーとの同期要件を満たさない場合、リーダー選出に参加できません。

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

Kafka は、特定のトピックに対して複数のパーティションを指定することにより、より優れた同時実行性 (負荷分散) を提供でき、各パーティションを異なるブローカーに分散できます。
パーティションでは対応するレプリカの数を指定できるため、メッセージストレージのセキュリティと災害復旧機能が大幅に向上しますが、それに応じて必要なストレージ領域も増加します。

Kafka における Zookeeper の役割

「Kafka における Zookeeper の役割を理解したい場合は、自分で Kafka 環境を構築し、Zookeeper にアクセスして、どのフォルダーが Kafka に関連し、各ノードにどのような情報が保存されているかを確認する必要があります。練習せずに読むだけではいけません。そうしないと、学んだことを結局忘れてしまいます。」

以下の記事では、Kafka 環境の構築方法を紹介します。心配しないでください。以降の記事を読めば、3 分で Kafka 環境を構築できます。

「この部分のコンテンツは、こちらの記事を参照し、参考にしています：https://www.jianshu.com/p/a036405f989c 。」

下の画像は、ローカルの Zookeeper です。これは、ローカルの Kafka に正常に関連付けられています (次のフォルダー構造は、アイデアプラグインの Zookeeper ツールを使用して実装されています)。

ZooKeeper は主に Kafka のメタデータ管理機能を提供します。

図から、Zookeeper は主に Kafka に対して次のことを実行していることがわかります。

ブローカー登録: Zookeeper には、ブローカーサーバーリストを記録するための専用ノードがあります。各ブローカーが起動すると、Zookeeper に登録されます。つまり、/brokers/ids の下に独自のノードが作成されます。各ブローカーは自身のIPアドレス、ポート、その他の情報をノードに記録します。
トピック登録: Kafka では、同じトピックのメッセージは複数のパーティションに分割され、複数のブローカーに分散されます。これらのパーティション情報とブローカーとの対応する関係も Zookeeper によって管理されます。たとえば、my-topic という名前のトピックを作成しましたが、このトピックには 2 つのパーティションがあります。 Zookeeper では、次のフォルダが作成されます: /brokers/topics/my-topic/partions/0、/brokers/topics/my-topic/partions/1
負荷分散: 前述のように、Kafka は特定のトピックに対して複数のパーティションを指定することにより、より優れた同時実行機能を提供でき、各パーティションを異なるブローカーに分散できます。同じトピックの異なるパーティションの場合、Kafka はこれらのパーティションを異なるブローカーサーバーに分散するように最善を尽くします。プロデューサーはメッセージを生成すると、それをさまざまなブローカーのパーティションに配信しようとします。コンシューマーが消費すると、Zookeeper は現在のパーティション数とコンシューマー数に基づいて動的な負荷分散を実現できます。
......

Kafka はどのようにしてメッセージの消費順序を保証するのでしょうか?

メッセージキューを使用する場合、メッセージの消費順序を厳密に保証する必要があるビジネスシナリオがよくあります。たとえば、2 つのメッセージを同時に送信します。これら 2 つのメッセージに対応する操作は、ユーザーのメンバーシップレベルの変更と、メンバーシップレベルに基づいた注文価格の計算です。これら 2 つのメッセージの消費順序が異なる場合、最終結果は完全に異なります。

Kafka のパーティションはメッセージが実際に保存される場所であり、送信するすべてのメッセージはここに配置されることがわかっています。パーティションはトピックの概念の中に存在し、特定のトピックに対して複数のパーティションを指定できます。

Kafka トピックパーティションレイアウト

メッセージがパーティションに追加されるたびに、上図に示すように、末尾追加方式が使用されます。 Kafka はパーティション内のメッセージの順序のみを保証できますが、トピック内のパーティションの順序は保証できません。

「メッセージがパーティションに追加されると、特定のオフセットが割り当てられます。Kafka はオフセットを使用して、パーティション内のメッセージの順序を確保します。」

したがって、メッセージの消費順序を保証する非常に簡単な方法があります。1 つのトピックは 1 つのパーティションにのみ対応します。確かにこれで問題は解決できますが、Kafka の本来の設計意図は損なわれます。

Kafka でメッセージを送信するときに、トピック、パーティション、キー、データの 4 つのパラメータを指定できます。メッセージを送信するときにパーティションを指定すると、すべてのメッセージが指定されたパーティションに送信されます。さらに、同じキーを持つメッセージは同じパーティションにのみ送信されることが保証されます。テーブル/オブジェクト ID をキーとして使用できます。

要約すると、Kafka でメッセージの消費順序を確保する方法は 2 つあります。