Kafka クイックスタートのヒント: 背景の紹介、アプリケーションシナリオの分析、コアアーキテクチャの分析

[[278300]]

1. 背景

はじめに: 実際、RabbitMQ を紹介したときに、この背景についてはすでに触れました。ここで Kakfa について話すときは、それを取り出してもう一度説明します。実際の戦闘について話す前に、理論を説明する必要があります。理論は補足的なもので、実践が主なものです。実際の戦闘に基づいて、理論、基礎となる原理、基礎となるソースコードをさらに理解することができます。次の記事またはビデオでは、公式 Web サイトにアクセスして、Kafka 環境の構築、Kafka の基本的な使い方、Kafka のフォールト トレランス テストについて説明します。知識を習得しながら、ついでに英語も学ぶことができます。

1) 問題の紹介:

ここで、次のようなユーザー登録システムを設計する必要があるとします。ユーザー登録が完了したら、ユーザーにアクティベーションメールを送信し、ユーザーアカウントを開き、ユーザーの IP、ユーザーデバイス、時間などの情報を記録する必要があります。

初期設計:

2) しかし問題は次のとおりです:

複数のシステムが密接に結合されているため、ユーザー登録の応答が非常に遅くなり、ユーザーエクスペリエンスに重大な影響を及ぼします。トラフィックが大きい場合、パフォーマンスはさらに悪化します。

3) メッセージミドルウェアの紹介:

上記の問題を解決するために、システム分離を実現するメッセージミドルウェアを導入しました。複数のシステムがメッセージ ミドルウェアを介して非同期的に通信します。最終的な設計図は次のとおりです。

これにより、システムの分離が実現されるだけでなく、システム応答の速度も向上します。

4) メッセージミドルウェアの紹介:

メッセージ キュー ミドルウェア (MQ) は、メッセージ キューとも呼ばれ、プラットフォームに依存しないデータ交換と、データ通信に基づく分散システムの構築のための効率的で信頼性の高いメッセージ伝送メカニズムの使用を指します。

2. アプリケーションシナリオ分析

1) 非同期通信

多くの場合、アプリケーション システム全体の動作を高速化するために、特定の要求に即座に応答する必要はありません。メッセージ ミドルウェアは非同期処理メカニズムを提供します。これにより、一部の要求情報をメッセージ ミドルウェアに配置できますが、すぐに処理されるのではなく、ゆっくりと処理されます。リソースが限られている場合でも、メッセージ ミドルウェアを使用するとシステム パフォーマンスが簡単に 2 倍になります。

例: ユーザー登録成功の電子メール通知。ユーザーのショッピング注文に関する情報通知。ビッグデータログの収集と処理

2) ピークシェービング

突然のトラフィックの急増がシステムを圧倒するのを防ぐために、メッセージミドルウェアを使用すると、突然のアクセス圧力をサポートできます。

3) ビジネスシステムの分離

システム間の結合関係が強すぎると、システムの設計が制限され、システムの複雑さが増します。メッセージ ミドルウェアを使用すると、すべての機能を同じシステムに統合するのではなく、1 つのシステムで指定された機能を完了するようにシステムをより適切に設計できます。

2. Kafka の紹介

メッセージ ミドルウェアとしての Kafka は、分散型のパブリッシュ/サブスクライブ ベースのメッセージング システムです。主な設計目標は次のとおりです。

O(1)の時間計算量でメッセージの永続性を提供し、テラバイトレベル以上のデータに対しても一定時間のアクセス性能を保証する

高いスループット。非常に安価な商用マシンでも、1台のマシンで1秒あたり10万件のメッセージの送信をサポートできます。

Kafka サーバー間のメッセージの分割と分散消費をサポートし、各パーティション内でのメッセージの連続送信を保証します。

オフラインデータ処理とリアルタイムデータ処理の両方をサポート

1. Kafka アーキテクチャ

用語集:

ブローカ

Kafka クラスターは 1 つ以上のブローカーで構成されます。 Kafka 環境を構築したサーバーはブローカーと呼ぶことができます。

トピック

Kafka クラスターに保存されるメッセージには、トピックと呼ばれるカテゴリがあります。 (ユーザーは、データの保存場所を気にすることなく、メッセージのトピックを指定するだけでデータを生成または使用できます。) トピックは、論理的にはキューと見なすことができます。各消費ではトピックを指定する必要があります。これは、メッセージをどのキューに入れるかを指定する必要があると簡単に理解でき、RabbitMQ に多少似ています。

パーティション

Kafka のスループットを水平方向に拡張するために、トピックは物理的に 1 つ以上のパーティションに分割されます。各パーティションは物理的にフォルダーに対応しており、そのフォルダーにはこのパーティションのすべてのメッセージとインデックス ファイルが格納されます。トピックを作成するときに、パーティションの数を指定できます。実際のデモンストレーションを行う際に再度ご説明させていただきます。

各メッセージはパーティションに追加され、ディスクに順番に書き込まれるため、効率が非常に高くなります (シーケンシャルなディスク書き込みはランダムなメモリ書き込みよりも効率的であることが検証されており、これは Kafka の高スループットにとって非常に重要な保証です)。

プロデューサー

Kafkaブローカーへのメッセージの発行を担当

消費者

メッセージを消費します。各コンシューマーは特定のコンシューマー グループに属します (各コンシューマーにグループ名を指定できます。グループ名が指定されていない場合は、デフォルト グループに属します)。同じトピックのメッセージは、同じコンシューマー グループ内の 1 つのコンシューマーのみが使用できますが、複数のコンシューマー グループが同時にメッセージを使用できます。

3. Kafka のその他のコアコンセプト

1. メッセージの保存

従来のメッセージ キューの多くは、メッセージが消費されるとそれを削除します。これにより、重複した消費が回避されるだけでなく、キューの長さが短くなり、効率が向上します。 Kafka クラスターは、メッセージが消費されたかどうかに関係なく、すべてのメッセージを保持します。もちろん、ディスクの制限により、すべてのデータを永続的に保持することは不可能です (実際にそうする必要はありません)。そのため、Kafka では古いデータを削除するための 2 つの戦略を提供しています。 1 つは時間に基づき、もう 1 つはパーティション ファイル サイズに基づきます。たとえば、$KAFKA_HOME/config/server.properties を設定して、Kafka が 1 週間以上古いデータを削除するようにしたり、パーティション ファイルが 1 GB を超えたときに古いデータを削除するように Kafka を設定したりできます。

2. 消費者団体

各コンシューマー インスタンスはコンシューマー グループに属し、各メッセージは同じコンシューマー グループ内の 1 つのコンシューマー インスタンスによってのみ消費されます。 (異なるコンシューマー グループが同時に同じメッセージを消費できます)

Kafka は、安定した状態では、各コンシューマー インスタンスが 1 つ以上の特定のパーティションからのデータのみを消費し、パーティションからのデータは特定のコンシューマー インスタンスによってのみ消費されることを保証します。この設計の欠点は、同じ消費者グループ内の消費者がデータを均等に消費することが不可能なことです。利点は、各コンシューマーが多数のブローカーと通信する必要がないため、通信のオーバーヘッドが削減されることです。また、割り当ての難しさも軽減され、実装も簡単になります。さらに、同じパーティション内のデータは順序付けられているため、この設計により、各パーティション内のデータも順番に使用されることが保証されます。

3. 消費者のバランス調整

Kafka は Zookeeper を通じてクラスター構成を管理し、コンシューマー グループが変更された場合 (たとえば、障害によりコンシューマーがオフラインになった場合) に再バランスを実行します。具体的な意味は次のとおりです。

コンシューマー グループ内のコンシューマーの数がパーティションの数より少ない場合、少なくとも 1 つのコンシューマーが複数のパーティションからデータを消費します。

コンシューマーの数がパーティションの数と同じ場合、正確に 1 つのコンシューマーが 1 つのパーティションのデータを消費します。

コンシューマーの数がパーティションの数より多い場合、一部のコンシューマーはトピックの下にあるメッセージを消費できなくなります。