基本概念、アーキテクチャ、新バージョンへのアップグレード - Kafka 知識システム (I)

[[408780]]

コンセプト

• Kafka は、LinkedIn によって最初に開発され、Scala (JAVA) で記述され、現在は Apache オープン ソース プロジェクトとなっている、高スループットの分散型パブリッシュ/サブスクライブ ベースのメッセージング システムです。
• 主に、アプリケーションの分離、非同期メッセージング、トラフィックのピークカットなどの問題を解決します。
• Kafka も実際にはマスター/スレーブ アーキテクチャであり、クラスター全体を調整および管理するコントローラー ロールを備えています。

キーワード

ブローカ

メッセージの保存と転送を担当する Kafka サーバー。

トピック

メッセージ カテゴリ、Kafka はトピックに応じてメッセージを分類します。リレーショナル データベースのテーブルに似ています。

パーティション

トピックのパーティション。トピックには複数のパーティションを含めることができ、トピック メッセージは各パーティションに保存されます。

オフセット

ログ内のメッセージの位置は、パーティション上のメッセージのオフセットとして理解でき、これはメッセージを表す一意のシーケンス番号でもあります。

プロデューサー

メッセージ プロデューサーは、Kafka クラスター内のブローカーにメッセージをプッシュします。

消費者

メッセージ コンシューマーは Kafka クラスターからメッセージをプルし、メッセージを消費します。

消費者団体

消費者のグループ化、各消費者はグループに属している必要があります

動物園の飼育員

クラスター ブローカー、トピック、パーティションなどのメタデータを保存します。また、ブローカーの障害検出、パーティション リーダーの選出、負荷分散などの機能も担います。

Kafka アーキテクチャ設計を抽象から具体まで理解する

マクロ的な視点で見ると、それはストレージシステムです。

詳しく言うと、複数のプロデューサー、複数のコンシューマー、ブローカー クラスター、および Kafka で構成されます。

さらに詳しく説明すると、ブローカーにはコントローラーの役割があります。各ブローカーは複数のトピックの異なるパーティションを保存でき、各パーティションにはリーダーとフォロワーが存在します。この情報はすべて zk に登録されます。

クラスタアーキテクチャと新バージョンの最適化の理解

コントローラ

よく知られているルールがあります。ビッグデータ分散ファイルシステムでは、95% がマスタースレーブアーキテクチャであり、一部は ElasticSearch などのピアツーピアアーキテクチャです。

Kafka にもマスタースレーブアーキテクチャがあります。マスターノードはコントローラーと呼ばれ、残りはスレーブノードと呼ばれます。コントローラーは、Zookeeper と連携して Kafka クラスター全体を管理する必要があります。

効果

クラスター全体を調整および管理します。

責任

• トピックの追加、削除、変更
• パーティションの再割り当て
• リーダー選挙
• メタデータ管理
• ブローカーメンバーの管理、ダウンタイムまたは参加

コントローラーの選出

これは Zookeeper に基づいて実装されており、Zookeeper の znode モデルと監視メカニズムを利用します。

コントローラのフェイルオーバー

単一障害点がありますが、各ブローカー ノードはコントローラーになることができます。

フェイルオーバーも、Zookeeper、znode モデル、監視メカニズム、/controller ノードに基づいて実装されます。

Kafka と Zookeeper はどのように連携しますか?

1. Kafka は Zookeeper クラスターに大きく依存しています。
2. すべてのブローカーは、コントローラーを選出することを目的として、起動時に Zookeeper に登録します。
3. 選挙のプロセスは非常に単純かつ粗雑です。最初に就任した人が就任するというプロセスです。アルゴリズムの問​​題は関係ありません。
4. コントローラーになると、Zookeeper 内の複数のディレクトリを監視します。
5. 登録時に、各ノードは必然的にホスト名、ポート番号、その他の情報を公開することになります。このとき、コントローラは登録されたスレーブ ノードのデータを (監視メカニズムを通じて) 読み取り、クラスターのメタデータ情報を生成し、この情報を他のサーバーに配布して、他のサーバーがクラスター内の他のメンバーの存在を認識できるようにします。

Kafka の新しいバージョンでは ZooKeeper が廃止されます!!!!!!

2021 年 3 月 30 日、Kafka を開発する Confluent 社は、次期バージョン 2.8 では ZooKeeper をまったく必要とせずに Kafka を実行できるようになるとブログ記事を公開しました。このバージョンでは、ZooKeeper に依存するコントローラーが Kafka Raft に基づく Quorm コントローラーに変換されます。

以前のバージョンでは、Kafka は ZooKeeper がないと機能しませんでした。ただし、2 つの異なるシステムを管理および展開すると、運用と保守の複雑さが 2 倍になるだけでなく、Kafka が重くなり、軽量環境での Kafka の適用が制限されます。同時に、ZooKeeper のパーティショニング機能によって Kafka の収容能力も制限されます。

初めて、ユーザーは ZooKeeper なしで Kafka を実行できるようになりました。

これはアーキテクチャの大幅なアップグレードであり、常に「重い」Kafka をよりシンプルにします。軽量なシングルプロセス展開は、ActiveMQ や RabbitMQ の代替として使用でき、エッジ シナリオや軽量ハードウェアを使用するシナリオにも適しています。

10 年間使用してきた ZooKeeper をなぜ放棄するのでしょうか?

zk の欠点:

• Zookeeper の欠点の 1 つは、同期されるデータが大きすぎることができないことです。
• ZooKeeper クラスター内のリーダーとフォロワー間のデータ同期の制限は 500M です。この 500 MB のデータがメモリにロードされると、約 3 GB のメモリを占有します。
• データが大きすぎるため、各選挙後にサーバーからフォロワーに同期する必要があり、次の 2 つの問題が簡単に発生する可能性があります。

1. 再選挙のきっかけ
2. ioが長すぎる

ZooKeeper は、クラスター内のトポロジの変更を更新するための Kafka のリーダーとして機能します。 ZooKeeper によって提供される通知に基づいて、プロデューサーとコンシューマーは、Kafka クラスター全体に新しいブローカーまたはブローカーの障害があるかどうかを検出します。容量拡張やパーティション移行などのほとんどの運用および保守操作では、ZooKeeper とのやり取りが必要です。

つまり、Kafka コードベースの大部分は、クラスター内の複数のブローカー間でのパーティション (つまりログ) の割り当て、リーダーシップの割り当て、障害の処理などの分散システム機能の実装を担当しています。業界で広く使用され、検証されている ZooKeeper は、分散コード作業の重要な部分です。

ZooKeeper がなければ、Kafka はプロセスを開始することすらできませんが、ZooKeeper に大きく依存することで、Kafka にも制約が生じます。

ただし、現在ほとんどの人は、ZK と組み合わせたバージョンの Kafka を使用しています。