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

[[315603]]

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

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

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

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

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

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

Kafkaを使い始める

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

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

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

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

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

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

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

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

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

Kafka メッセージ モデル

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

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

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

キューモデルの問題

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Kafka における Zookeeper の役割

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. 1 つのトピックは 1 つのパーティションにのみ対応します。
2. (推奨) メッセージを送信するときにキー/パーティションを指定します。

もちろん、上記の 2 つの方法以外にも方法はあります。上記2つの方法の方が分かりやすいと思います。