Kafka は優れた分散メッセージ ミドルウェアであり、多くのシステムでメッセージ通信に Kafka が使用されています。 [[346129]] 画像はPexelsより
分散メッセージング システムを理解して使用することは、バックエンド開発者にとってほぼ必須のスキルになっています。今日は、Kafka の面接でよくある質問から始めて、Kafka についてお話ししたいと思います。 マインドマップ 分散メッセージミドルウェアについて話す インタビューの質問: - 分散メッセージングミドルウェアとは何ですか?
- メッセージミドルウェアの役割は何ですか?
- メッセージミドルウェアの使用シナリオは何ですか?
- メッセージミドルウェアの選択?
メッセージキュー 分散メッセージングは通信メカニズムです。 RPC、HTTP、RMI などとは異なり、メッセージ ミドルウェアは通信に分散中間エージェントを使用します。 図に示すように、メッセージ ミドルウェアを導入すると、上流の業務システムがメッセージを送信し、そのメッセージがまずメッセージ ミドルウェアに格納され、その後、メッセージ ミドルウェアが対応する業務モジュール アプリケーションにメッセージを配信します (分散プロデューサー コンシューマー モード)。 この非同期アプローチにより、サービス間の結合度が低下します。 建築 メッセージ ミドルウェアを定義します。 - プラットフォームに依存しないデータ交換には、効率的で信頼性の高いメッセージ パッシング メカニズムを使用します。
- データ通信に基づいて分散システムを統合します。
- メッセージ パッシングおよびメッセージ キューイング モデルを提供することにより、分散環境でプロセス間通信を拡張できます。
システム アーキテクチャ内の追加コンポーネントを参照すると、必然的にシステム アーキテクチャの複雑さが増し、運用と保守が難しくなります。では、システムで分散メッセージ ミドルウェアを使用する利点は何でしょうか? メッセージ ミドルウェアはシステム内でどのような役割を果たしますか? - デカップリング
- 冗長性(ストレージ)
- スケーラビリティ
- ピークシェービング
- 回復可能性
- 注文保証
- バッファ
- 非同期通信
面接中、面接官は面接対象者がオープンソース コンポーネントを選択できるかどうかを懸念することがよくあります。これにより、面接対象者の知識の広さ、特定のタイプのシステムに関する知識の深さをテストできるほか、面接対象者がシステム全体を把握し、システム アーキテクチャを設計する能力も示されます。 オープンソースの分散メッセージング システムは数多く存在し、メッセージング システムによって特性が異なります。メッセージング システムを選択するには、各メッセージング システムについてある程度理解するだけでなく、独自のシステム要件を明確に理解することも必要です。 以下は、いくつかの一般的な分散メッセージング システムの比較です。 メッセージキューの選択 回答キーワード: - 分散メッセージミドルウェアとは何ですか?通信、キュー、配布、プロデューサー-コンシューマー モデル。
- メッセージミドルウェアの役割は何ですか?デカップリング、ピーク処理、非同期通信、バッファリング。
- メッセージミドルウェアの使用シナリオは何ですか?非同期通信、メッセージの保存および処理。
- メッセージミドルウェアを選択するには?言語、プロトコル、HA、データの信頼性、パフォーマンス、トランザクション、エコロジー、シンプルさ、プッシュプル モード。
Kafka の基本概念とアーキテクチャ インタビューの質問: - Kafka のアーキテクチャを簡単に説明してください。
- Kafka はプッシュ モードですか、それともプル モードですか?プッシュとプルの違いは何ですか?
- Kafka はどのようにメッセージをブロードキャストしますか?
- Kafka メッセージは順番通りですか?
- Kafka は読み取りと書き込みの分離をサポートしていますか?
- Kafka はどのようにして高いデータ可用性を確保するのでしょうか?
- Kafka における Zookeeper の役割は何ですか?
- トランザクションはサポートされていますか?
- パーティションの数を減らすことはできますか?
アーキテクチャ図 Kafka アーキテクチャの一般的な概念: - プロデューサー: プロデューサーはメッセージを送信する当事者です。プロデューサーはメッセージを作成し、それを Kafka に送信する責任を負います。
- 消費者: 消費者はメッセージを受信する当事者です。コンシューマーは Kafka に接続してメッセージを受信し、対応するビジネス ロジック処理を実行します。
- コンシューマー グループ: コンシューマー グループには 1 人以上のコンシューマーを含めることができます。マルチパーティション + マルチコンシューマー アプローチを使用すると、ダウンストリーム データの処理速度が大幅に向上します。
同じコンシューマー グループ内のコンシューマーは、メッセージを繰り返し消費しません。同様に、異なるコンシューマー グループのコンシューマーは、メッセージを消費するときに互いに影響を及ぼしません。 Kafka は、コンシューマー グループを通じてメッセージ P2P モードとブロードキャスト モードを実装します。 - ブローカー: サービス プロキシ ノード。 Broker は Kafka のサービス ノード、つまり Kafka のサーバーです。
- トピック: Kafka 内のメッセージはトピックに分割されます。プロデューサーは特定のトピックにメッセージを送信し、コンシューマーはトピックからのメッセージをサブスクライブして消費する責任を負います。
- パーティション: トピックは、複数のパーティションに分割できる論理的な概念です。各パーティションは単一のトピックに属します。
同じトピックの下にある異なるパーティションに含まれるメッセージは異なります。パーティションは、ストレージ レベルで追加可能なログ ファイルと見なすことができます。メッセージがパーティション ログ ファイルに追加されると、特定のオフセットが割り当てられます。 - オフセット: オフセットは、パーティション内のメッセージの一意の識別子です。 Kafka はこれを使用して、パーティション内のメッセージの順序を確保します。ただし、オフセットはパーティションにまたがりません。つまり、Kafka はトピックの順序ではなくパーティションの順序を保証します。
- レプリケーション: レプリケーションは、Kafka がデータの高可用性を確保する方法です。 Kafka の同じパーティション内のデータは、複数のブローカー上に複数のコピーとして存在できます。通常、プライマリ コピーのみが外部に対して読み取りおよび書き込みサービスを提供します。プライマリ コピーが配置されているブローカーがクラッシュしたり、ネットワーク障害が発生したりした場合、Kafka はコントローラーの管理下にある新しいリーダー コピーを再選択して、外部に読み取りおよび書き込みサービスを提供します。
- レコード: 実際に Kafka に書き込まれ、読み取ることができるメッセージ レコード。各レコードにはキー、値、タイムスタンプが含まれます。
Kafka トピック パーティション レイアウトは以下のとおりです。 テーマ Kafka はトピックをパーティション化し、パーティションを同時に読み取りおよび書き込みできます。 Kafka コンシューマー オフセットは以下のとおりです。 消費者オフセット Zookeeper のアーキテクチャは次のとおりです。 - ブローカー登録: ブローカーは分散して展開され、互いに独立しています。 Zookeeper は、クラスターに登録されているすべてのブローカー ノードを管理するために使用されます。
- トピック登録: Kafka では、同じトピックのメッセージは複数のパーティションに分割され、複数のブローカーに分散されます。これらのパーティション情報とブローカーとの対応する関係も Zookeeper によって管理されます。
- プロデューサーの負荷分散: 同じトピック メッセージは複数のブローカーに分割されて分散されるため、プロデューサーはこれらの分散ブローカーにメッセージを合理的に送信する必要があります。
- コンシューマーの負荷分散: プロデューサーと同様に、Kafka のコンシューマーも、複数のコンシューマーが対応するブローカー サーバーからメッセージを適切に受信できるように、負荷分散する必要があります。各コンシューマー グループには複数のコンシューマーが含まれており、各メッセージはグループ内の 1 つのコンシューマーにのみ送信されます。さまざまなコンシューマー グループは、互いに干渉することなく、独自の特定のトピックでメッセージを消費します。
回答キーワード: - Kafka のアーキテクチャについて簡単に説明していただけますか?プロデューサー、コンシューマー、コンシューマー グループ、トピック、パーティション。
- Kafka はプッシュ モードですか、それともプル モードですか?プッシュとプルの違いは何ですか? Kafka プロデューサーはプッシュ モードを使用してブローカーにメッセージを送信し、コンシューマーはプル モードを使用してメッセージを消費します。プル モードでは、コンシューマーがオフセットを自分で管理できるため、読み取りパフォーマンスが向上します。
- Kafka はどのようにメッセージをブロードキャストしますか?消費者グループ。
- Kafka メッセージは順序付けられていますか?トピック レベルは順序付けられていませんが、パーティション レベルは順序付けられています。
- Kafka は読み取りと書き込みの分離をサポートしていますか?いいえ、リーダーのみが外部に読み取り/書き込みサービスを提供します。
- Kafka はどのようにして高いデータ可用性を確保するのでしょうか?レプリカ、Ack、HW。
- Kafka における zookeeper の役割は何ですか?クラスター管理とメタデータ管理。
- トランザクションをサポートしていますか?トランザクションは 0.11 以降でサポートされ、「正確に 1 回」を実現できます。
- パーティションの数を減らすことはできますか?いいえ、データは失われます。
Kafka の使用法 インタビューの質問: - Kafka にはどのようなコマンドライン ツールがありますか?どれを使ったことがありますか?
- Kafka Producer の実行プロセスとは何ですか?
- Kafka Producer の一般的な構成は何ですか?
- Kafka メッセージを整然とさせるにはどうすればよいでしょうか?
- Producer はどのようにしてデータが失われないようにするのでしょうか?
- プロデューサーのパフォーマンスを向上させるにはどうすればいいですか?
- 同じグループ内のコンシューマーの数がパーツの数より多い場合、Kafka はどのように処理しますか?
- Kafka Consumer はスレッドセーフですか?
- Kafka Consumer を使用してメッセージを消費する場合のスレッド モデルについて説明します。なぜこのように設計されているのでしょうか?
- Kafka Consumer の一般的な構成は何ですか?
- コンシューマーはいつクラスターから追い出されますか?
- Consumer が参加または離脱すると、Kafka はどのように反応しますか?
- リバランスとは何ですか? また、いつ行われますか?
コマンドラインツール Kafka のコマンドライン ツールは、Kafka パッケージの /bin ディレクトリにあり、主にサービスおよびクラスター管理スクリプト、構成スクリプト、情報表示スクリプト、トピック スクリプト、クライアント スクリプトなどが含まれます。 - kafka-configs.sh: 構成管理スクリプト。
- kafka-console-consumer.sh: kafka コンシューマー コンソール。
- kafka-console-producer.sh: kafka プロデューサー コンソール。
- kafka-consumer-groups.sh: kafka コンシューマー グループ関連の情報。
- kafka-delete-records.sh: 低いウォーターマークのログ ファイルを削除します。
- kafka-log-dirs.sh: kafka メッセージ ログ ディレクトリ情報。
- kafka-mirror-maker.sh: 異なるデータセンターで kafka クラスターを複製するためのツール。
- kafka-preferred-replica-election.sh: 優先レプリカの選択をトリガーします。
- kafka-producer-perf-test.sh: kafka プロデューサーのパフォーマンス テスト スクリプト。
- kafka-reassign-partitions.sh: パーティションの再割り当てスクリプト。
- kafka-replica-verification.sh: レプリケーションの進行状況検証スクリプト。
- kafka-server-start.sh: kafka サービスを開始します。
- kafka-server-stop.sh: kafka サービスを停止します。
- kafka-topics.sh: トピック管理スクリプト。
- kafka-verifiable-consumer.sh: 検証可能な kafka コンシューマー。
- kafka-verifiable-producer.sh: 検証可能な kafka プロデューサー。
- zookeeper-server-start.sh: zookeeper サービスを開始します。
- zookeeper-server-stop.sh: zookeeper サービスを停止します。
- zookeeper-shell.sh: zk クライアント。
通常、kafka-console-consumer.sh および kafka-console-producer.sh スクリプトを使用して、Kafka の生成と消費をテストできます。 kafka-consumer-groups.sh はクラスター内のトピックを表示および管理できます。 kafka-topics.sh は通常、Kafka コンシューマー グループのステータスを表示するために使用されます。 カフカプロデューサー Kafka プロデューサーの通常の生成ロジックには、次の手順が含まれます。 - プロデューサー インスタンスに共通するプロデューサー クライアント パラメータを構成します。
- 送信するメッセージを構築します。
- メッセージを送信します。
- プロデューサー インスタンスを閉じます。
プロデューサーがメッセージを送信するプロセスを下の図に示します。インターセプター、シリアライザー、パーティショナーを通過し、最終的にアキュムレーターによってブローカーにバッチで送信される必要があります。 プロデューサー Kafka プロデューサーには次の必須パラメータが必要です。 - bootstrap.server: Kafka Broker のアドレスを指定します。
- key.serializer: キーシリアライザー。
- value.serializer: 値シリアライザー。
共通パラメータ: - batch.num.messages、デフォルト値: 200、毎回のバッチ メッセージの数、asyc でのみ機能します。
- request.required.acks、デフォルト値: 0、0 はプロデューサーがリーダーの確認を待つ必要がないことを意味し、1 はリーダーがローカル ログへの書き込みを確認してすぐに確認する必要があることを意味し、-1 はすべてのバックアップが完了した後に確認することを意味します。
このパラメータは非同期モードでのみ機能します。このパラメータの調整は、データ損失と送信効率の間のトレードオフです。データ損失は気にしないが効率を重視する場合は、0 に設定することを検討してください。これにより、プロデューサーがデータを送信する効率が大幅に向上します。 - request.timeout.ms、デフォルト値: 10000、確認タイムアウト。
- partitioner.class、デフォルト値: kafka.producer.DefaultPartitioner、kafka.producer.Partitioner を実装する必要があり、キーに基づいてパーティション分割戦略を提供します。
同じタイプのメッセージを順番に処理する必要がある場合、同じタイプのデータを同じパーティションに割り当てるように割り当て戦略をカスタマイズする必要があります。 - producer.type、デフォルト値: sync、メッセージが同期的に送信されるか、非同期的に送信されるかを指定します。非同期の asyc バッチ送信では kafka.producer.AyncProducer が使用され、同期同期では kafka.producer.SyncProducer が使用されます。同期送信と非同期送信もメッセージ生成の効率に影響します。
- compression.topic、デフォルト値: none、メッセージの圧縮、デフォルトでは圧縮なし。その他の圧縮方法には、「gzip」、「snappy」、「lz4」などがあります。メッセージの圧縮により、ネットワークの転送量とネットワーク IO が大幅に削減され、全体的なパフォーマンスが向上します。
- compressed.topics、デフォルト値: null。圧縮が設定されている場合は、圧縮する特定のトピックを指定できます。指定しない場合は、すべてのトピックが圧縮されます。
- message.send.max.retries、デフォルト値: 3、メッセージを送信する最大試行回数。
- retry.backoff.ms、デフォルト値: 300、試行ごとに追加される間隔時間。
- topic.metadata.refresh.interval.ms、デフォルト値: 600000、メタデータを定期的に取得する時間。
パーティションが失われ、リーダーが利用できない場合は、プロデューサーもメタデータを積極的に取得します。 0 の場合、メッセージが送信されるたびにメタデータが取得されますが、これは推奨されません。負の場合、失敗した場合にのみメタデータが取得されます。 - queue.buffering.max.ms、デフォルト値: 5000、プロデューサー キューにキャッシュされるデータの最大時間 (asyc のみ)。
- queue.buffering.max.message、デフォルト値: 10000、プロデューサーによってキャッシュされるメッセージの最大数 (asyc の場合のみ)。
- queue.enqueue.timeout.ms、デフォルト値: -1、0。キューがいっぱいになるとドロップします。負の値はキューがいっぱいのときにブロックすることを意味します。正の値は、キューがいっぱいの場合に対応する時間ブロックすることを意味します。 asyc のみ。
Kafka コンシューマー Kafka にはコンシューマ グループの概念があります。各コンシューマーは、割り当てられているパーティションからのメッセージのみを消費できます。各パーティションは、コンシューマー グループ内の 1 つのコンシューマーのみが使用できます。したがって、同じコンシューマー グループ内のコンシューマーの数がパーティションの数を超えると、一部のコンシューマーには消費するパーティションが割り当てられません。 消費者グループと消費者の関係は次の図に示されています。 消費者団体 Kafka コンシューマー クライアントがメッセージを消費するには、通常、次の手順が含まれます。 - クライアントを構成してコンシューマーを作成する
- トピックを購読する
- メッセージを引き出して消費する
- 消費変位を提出する
- コンシューマーインスタンスを閉じる
プロセス Kafka の Consumer クライアントはスレッドセーフではないため、スレッドの安全性を確保し、消費パフォーマンスを向上させるために、Consumer 側で Reactor に似たスレッド モデルを使用してデータを消費できます。 消費モデル Kafka コンシューマー パラメータ: - bootstrap.servers: ホスト:ポートの形式でブローカー アドレスに接続します。
- group.id: コンシューマーが属するコンシューマー グループ。
- key.deserializer: プロデューサーの key.serializer (キーのデシリアライズ方法) に対応します。
- value.deserializer: プロデューサーの value.serializer (値のデシリアライズ方法) に対応します。
- session.timeout.ms: コーディネーターが障害を検出するまでにかかる時間。デフォルト値は 10 秒です。このパラメータは、ハートビートの有効期限と同様に、コンシューマー グループが (グループ メンバー comsummer) クラッシュをアクティブに検出する時間間隔です。
- auto.offset.reset: このプロパティは、オフセットのないパーティションまたは無効なオフセット (コンシューマーが長期間非アクティブであり、現在のオフセットが古くて削除されている) を持つパーティションを読み取るときにコンシューマーが実行する操作を指定します。デフォルト値は latest で、これは最新のレコード (コンシューマーの起動後に生成されたレコード) からデータを読み取ることを意味します。もう 1 つの値は earliest です。これは、オフセットが無効な場合に、コンシューマーが開始位置からデータを読み取ることを意味します。
- enable.auto.commit: 変位を自動的にコミットするかどうか。 false の場合は、プログラム内で手動で変位をコミットする必要があります。正確に 1 回のセマンティクスの場合は、ビット シフトを手動でコミットする方が適切です。
- fetch.max.bytes: 一度に取得する最大バイト数。
- max.poll.records: 1 回のポーリング呼び出しで返されるメッセージの最大数。処理ロジックが非常に軽量な場合は、この値を適切に増やすことができます。ただし、max.poll.records 個のデータは session.timeout.ms 内に処理する必要があります。デフォルト値は 500 です。
- request.timeout.ms: リクエスト応答の最大待機時間。タイムアウト期間内に応答が受信されない場合、Kafka はメッセージを再送信するか、再試行回数を超えた場合は直接失敗と見なします。
Kafka の再バランス リバランスは、本質的には、コンシューマー グループ内のすべてのコンシューマーが、サブスクライブされたトピックの各パーティションを割り当てるために合意に達する方法を指定するプロトコルです。 たとえば、グループの下に 20 の Consumer があり、100 個のパーティションを持つ Topic をサブスクライブしているとします。 通常の状況では、Kafka は各コンシューマーに平均 5 つのパーティションを割り当てます。この分配プロセスはリバランスと呼ばれます。 ①いつリバランスするべきか?これも、よく言われる質問です。 リバランスのトリガー条件は 3 つあります。 - グループ メンバーシップの変更 (新しい消費者がグループに参加、既存の消費者がグループを離れる、または既存の消費者がクラッシュする - この 2 つの違いについては後で説明します)
- 購読トピックの数が変更されました
- サブスクリプショントピックのパーティション数が変更されました
②グループ内でパーティションを割り当てるには? Kafka はデフォルトで、範囲とラウンドロビンの 2 つの割り当て戦略を提供します。もちろん、Kafka はプラグ可能な割り当て戦略を使用しており、独自のアロケータを作成してさまざまな割り当て戦略を実装できます。 回答キーワード: - Kafka にはどのようなコマンドライン ツールがありますか?どれを使ったことがありますか? /bin ディレクトリ、Kafka クラスターの管理、トピックの管理、Kafka の生成と使用。
- Kafka プロデューサーの実行プロセス - インターセプター、シリアライザー、パーティショナー、アキュムレーター。
- Kafka Producer の一般的な構成は何ですか?ブローカー構成、Ack 構成、ネットワークおよび送信パラメータ、圧縮パラメータ、Ack パラメータ。
- Kafka メッセージを順序付けるにはどうすればよいでしょうか? Kafka はトピック レベルでは順序付けされておらず、パーティション レベルでのみ順序付けされます。したがって、処理順序を保証するために、パーティショナーをカスタマイズし、順番に処理する必要があるデータを同じパーティションに送信できます。
- プロデューサーはどのようにしてデータ転送が失われないことを保証するのでしょうか? Ack メカニズム、再試行メカニズム。
- Producer のパフォーマンスを向上させるにはどうすればよいでしょうか?バッチ処理、非同期、圧縮。
- 同じグループ内のコンシューマーの数がパーツの数より多い場合、Kafka はどのように処理しますか?余分な部分は役に立たず、データを消費しません。
- Kafka Consumer はスレッドセーフですか?安全ではない、シングルスレッド消費、マルチスレッド処理
- Kafka Consumer を使用してメッセージを消費する場合のスレッド モデルについて説明します。なぜこのように設計されているのでしょうか?引き抜きと加工は分離しています。
- Kafka Consumer の一般的な構成は何ですか?ブローカー、ネットワーク、プル パラメーター、ハートビート パラメーター。
- コンシューマーはいつクラスターから追い出されますか?クラッシュ、ネットワーク異常、処理時間が長すぎる、送信変位タイムアウト。
- Consumer が参加または離脱すると、Kafka はどのように反応しますか?リバランスを実行します。
- リバランスとは何ですか? また、いつ実行されますか?話題が変われば、消費者も変わります。
高い可用性とパフォーマンス インタビューの質問: - Kafka はどのようにして高可用性を確保するのでしょうか?
- Kafka の配信セマンティクスとは何ですか?
- Replic は何をしますか?
- AR、ISRとは何ですか?
- リーダーとフラワーとは何ですか?
- Kafka の HW、LEO、LSO、LW などはどういう意味ですか?
- 優れたパフォーマンスを確保するために Kafka は何を行いますか?
パーティションとレプリカ パーティションのレプリカ 分散データ システムでは、システムの処理能力を向上させるためにパーティションがよく使用され、データの高可用性を確保するためにはレプリカが使用されます。 複数のパーティションは、同時に処理する機能を意味します。これらの複数のコピーのうち、リーダーは 1 つだけであり、その他はフォロワー コピーです。 リーダーレプリカのみが外部世界にサービスを提供できます。複数のフォロワー レプリカは通常、リーダー レプリカとは異なるブローカーに保存されます。 このようなメカニズムにより、高可用性が実現されます。マシンに障害が発生した場合、他の Follower コピーがすぐに正常に動作し、外部へのサービスの提供を開始できます。 ①フォロワーレプリカが読み取りサービスを提供しないのはなぜですか? この問題は本質的に、パフォーマンスと一貫性の間のトレードオフです。フォロワーのレプリカが外部の世界にもサービスを提供したらどうなるか想像してみてください。 まず、パフォーマンスは確実に向上します。しかし同時に、一連の問題も発生します。データベース トランザクションのファントム リードやダーティ リードに似ています。 たとえば、Kafka トピック a にデータを書き込むと、コンシューマー b はトピック a からデータを消費しますが、コンシューマー b が読み取るパーティション コピーに最新のメッセージが書き込まれていないため、データを消費できないことがわかります。 このとき、別のコンシューマー c はリーダー コピーを消費するため、最新のデータを消費できます。 Kafka は、WH と Offset の管理を通じて、コンシューマーが消費できるデータと現在書き込まれているデータを決定します。 透かし ②リーダーだけが外部に読み取りサービスを提供できますが、リーダーをどのように選出するのでしょうか? Kafka は、リーダー レプリカと同期されたレプリカを ISR レプリカ セットに配置します。もちろん、リーダー レプリカは常に ISR レプリカ セット内に存在します。特殊なケースでは、ISR レプリカ セット内にリーダー レプリカが 1 つだけ存在することもあります。 リーダーに障害が発生すると、Kakfa は Zookeeper を通じてこれを検出し、ISR レプリカから新しいレプリカを選択してリーダーとなり、外部にサービスを提供します。 しかし、別の問題があります。前述のように、ISR レプリカ セットにはリーダーのみが存在する場合があります。リーダー レプリカがハングアップすると、ISR セットは空になります。こういう時、私たちは何をすべきでしょうか? このとき、unclean.leader.election.enable パラメータが true に設定されている場合、Kafka は非同期レプリカ、つまり ISR レプリカ セットに含まれていないレプリカからリーダーとなるレプリカを選択します。 ③コピーが存在するとコピー同期の問題が発生する Kafka は、割り当てられたすべてのレプリカ (AR) 間で利用可能なレプリカ リスト (ISR) を維持します。プロデューサーがブローカーにメッセージを送信すると、応答が成功する前に ACK 構成に基づいてメッセージを同期するために待機する必要があるレプリカの数を決定します。 Broker は ReplicaManager サービスを使用して、Flower と Leader 間のデータ同期を管理します。 同期 パフォーマンスの最適化: - パーティションの同時実行。
- ディスクを順番に読み書きします。
- ページ キャッシュ: ページごとに読み取りおよび書き込みます。
- 事前読み取り: Kafka は消費するメッセージを事前にメモリに読み取ります。
- 高性能シリアル化 (バイナリ)。
- メモリマッピング。
- ロックフリーのオフセット管理: 同時実行機能が向上します。
- Java NIO モデル。
- バッチ: バッチ読み取りと書き込み。
- 圧縮: メッセージの圧縮、ストレージの圧縮、ネットワークと IO のオーバーヘッドの削減。
パーティションの同時実行 一方、異なるパーティションを異なるマシンに配置できるため、クラスターの利点を最大限に活用してマシン間の並列処理を実現できます。 一方、パーティションは物理的にフォルダに対応しているため、同一ノード上に複数のパーティションが存在する場合でも、同一ノード上の異なるパーティションを異なるディスクドライブに配置するように構成することができ、ディスク間の並列処理を実現し、複数ディスクの利点を最大限に発揮することができます。 シーケンシャル読み取りと書き込み Kafka の各パーティション ディレクトリの下のファイルは、同じサイズのデータ ファイルに均等に分割されます (ファイルのデフォルト サイズは 500 MB ですが、手動で設定できます)。 各データ ファイルはセグメント ファイルと呼ばれ、各セグメントは追加メソッドを使用してデータを追加します。 データの追加 回答キーワード: - Kafka はどのようにして高可用性を確保するのでしょうか?レプリカ、プロデューサー Ack、再試行、自動リーダー選出、コンシューマーの自己バランス調整を通じて、高いデータ可用性を保証します。
- Kafka の配信セマンティクスとは何ですか?配信セマンティクスは通常、少なくとも 1 回、最大で 1 回、正確に 1 回です。 Kafka は、最初の 2 つを Ack 構成を通じて実装します。
- Replicの役割は?データの高可用性を実現します。
- AR、ISR とは何ですか?AR: 割り当てられたレプリカ。 AR は、トピックが作成され、パーティションが作成されるときに割り当てられるレプリカのセットです。レプリカの数はレプリケーション係数によって決まります。
ISR: 同期レプリカ。 Kafka における特に重要な概念は、リーダーと同期される AR 内のレプリカのセットを指します。 AR 内のレプリカは ISR に含まれない可能性がありますが、リーダー レプリカは当然 ISR に含まれます。 ISR に関して、面接でよく聞かれる質問のもう 1 つは、コピーが ISR に属するかどうかをどのように判断するかということです。 現在の判断基準は、フォロワー レプリカの LEO がリーダー LEO より遅れている時間が、ブローカー側のパラメータ replica.lag.time.max.ms 値を超えているかどうかです。超過した場合、レプリカは ISR から削除されます。 - リーダーとフラワーとは何ですか?上記を参照してください。
- Kafka の HW は何の略ですか?最高水準点。これは、消費者が読み取ることができるメッセージの範囲を制御する重要なフィールドです。
通常のコンシューマーは、リーダー レプリカのログ開始オフセットと HW (含まれない) 間のすべてのメッセージのみを「表示」できます。水面より上のメッセージは消費者には見えません。 - 優れたパフォーマンスを確保するために Kafka は何を行いましたか?パーティションの同時実行、シーケンシャルなディスクの読み取りと書き込み、ページ キャッシュの圧縮、高性能シリアル化 (バイナリ)、メモリ マッピング、ロックフリーのオフセット管理、および Java NIO モデル。
要約する この記事では、Kafka の実装の詳細やソース コードの分析については説明しません。しかし、Kafka は確かに優れたオープン ソース システムであり、その優れたアーキテクチャとソース コードの設計の多くは学ぶ価値があります。 著者: コードバイト 編集者:タオ・ジアロン 出典: 公開アカウント MageByte (ID: MageByte) から転載 |