Kafka は優れた分散メッセージ ミドルウェアであり、メッセージ通信用の多くのシステムで使用されています。分散メッセージング システムを理解して使用することは、バックエンド開発者にとってほぼ必須のスキルとなっています。今日の 马哥byte
は、Kafka の面接でよくある質問から始めて、Kafka についてお話します。
分散メッセージング ミドルウェアについて話しましょう
質問
- #分散メッセージング ミドルウェアとは何ですか?
- メッセージミドルウェアの役割は何ですか?
- メッセージミドルウェアの使用シナリオは何ですか?
#メッセージミドルウェアの選択?
メッセージ ミドルウェアの定義:
- #プラットフォームに依存しないデータ交換のための効率的で信頼性の高いメッセージ パッシング メカニズムの使用
#データ通信に基づく分散システムの統合 メッセージ パッシング モデルとメッセージ キューイング モデルを提供することにより、プロセス間通信を分散環境で拡張できます。 -
# システム アーキテクチャで追加のコンポーネントを参照すると、必然的にアーキテクチャの複雑さが改善されますシステムの複雑さと運用保守の難しさです。
システムで分散メッセージ ミドルウェアを使用する利点は何ですか?システムにおけるメッセージミドルウェアの役割は何ですか?
#デカップリング
-
- 面接中、面接官はオープン ソース コンポーネントを選択できるかどうかをよく気にします。面接官の特定の種類のシステムに関する知識の深さをテストすることもでき、面接官がシステム全体とシステム アーキテクチャ設計を把握する能力を示すこともできます。オープン ソースの分散メッセージング システムは数多くあり、メッセージング システムが異なれば特性も異なります。メッセージング システムを選択するには、各メッセージング システムをある程度理解するだけでなく、独自のシステム要件を明確に理解する必要があります。
以下は、いくつかの一般的な分散メッセージング システムの比較です:
キーワードを答える
- 分散型メッセージミドルウェアとは?通信、キュー、分散型、生産者/消費者モデル。
- メッセージミドルウェアの役割は何ですか?デカップリング、ピーク処理、非同期通信、バッファリング。
- メッセージミドルウェアの使用シナリオは何ですか?非同期通信、メッセージの保存と処理。
- #メッセージミドルウェアの選択?言語、プロトコル、HA、データの信頼性、パフォーマンス、トランザクション、エコロジー、シンプルさ、プッシュプル モード。
#Kafka の基本概念とアーキテクチャ
#質問
Kafka のアーキテクチャについて簡単に説明してください。 Kafka はプッシュ モードですか? プル モードですか? プッシュ モードとプル モードの違いは何ですか? Kafka はどのようにメッセージをブロードキャストするのでしょうか? Kafka のメッセージは正しいですか? Kafka は読み取りと書き込みの分離をサポートしていますか? Kafka はどのようにして高いデータ可用性を確保しますか? Kafka における動物園の飼育員の役割は何ですか? -
# トランザクションをサポートしていますか?
-
Kafka アーキテクチャの一般概念:
- プロデューサー: プロデューサー、つまりメッセージを送信する当事者。プロデューサーはメッセージを作成して Kafka に送信する責任があります。
- コンシューマ: コンシューマ、つまりメッセージを受信する当事者。コンシューマは Kafka に接続してメッセージを受信し、対応するビジネス ロジック処理を実行します。
- コンシューマ グループ: コンシューマ グループには 1 つ以上のコンシューマを含めることができます。マルチパーティションおよびマルチコンシューマのアプローチを使用すると、ダウンストリーム データの処理速度が大幅に向上します。同じコンシューマ グループ内のコンシューマは、メッセージを繰り返し消費しません。同様に、異なるコンシューマ グループ内のコンシューマによって送信されたメッセージは、相互に影響を与えません。 Kafka は、コンシューマ グループを通じてメッセージ P2P モードとブロードキャスト モードを実装します。
- ブローカー: サービス プロキシ ノード。 Broker は Kafka のサービス ノード、つまり Kafka のサーバーです。
- トピック: Kafka のメッセージはトピック ユニットに分割されており、プロデューサは特定のトピックにメッセージを送信し、コンシューマはトピック メッセージをサブスクライブして消費する責任があります。
- パーティション: トピックは複数のパーティションに細分化できる論理概念であり、各パーティションは 1 つのトピックにのみ属します。同じトピック内の異なるパーティションには、異なるメッセージが含まれます。パーティションは、ストレージ レベルで追加可能なログ ファイルと見なされます。メッセージがパーティション ログ ファイルに追加されると、特定のオフセットが割り当てられます。)。
- Offset: offset は、パーティション内のメッセージの一意の識別子です。Kafka は、パーティション内のメッセージの順序を保証するためにこれを使用します。ただし、offset はパーティションにまたがりません。つまり、Kafka は、トピックの順序ではなくパーティションの順序であることを保証します。
- レプリケーション: レプリカは、高いデータ可用性を確保する Kafka の方法です。同じパーティション内の Kafka のデータは、複数のブローカー上に複数のコピーを持つことができます。通常、外部読み取りおよび書き込みサービスを提供するのはプライマリ コピーのみです。プライマリ レプリカが配置されているブローカーがクラッシュするか、ネットワーク障害が発生すると、Kafka はコントローラーの管理下で新しいリーダー レプリカを再選択し、外部読み取りおよび書き込みサービスを提供します。
- レコード: 実際に Kafka に書き込まれ、読み取ることができるメッセージ レコード。各レコードにはキー、値、タイムスタンプが含まれます。
Kafka トピック パーティションのレイアウト
Kafka はトピックをパーティションに分割します。読み取りと書き込みを同時に行うことができます。
Kafka コンシューマ オフセット
#動物園の飼育員
#動物園の飼育員ブローカーの登録: ブローカーは分散方式でデプロイされ、互いに独立しています。Zookeeper は、クラスターに登録されているすべてのブローカー ノードを管理するために使用されます。
-
トピックの登録: Kafka では、同じトピックのメッセージが複数のパーティションに分割され、複数の Broker に分散されます。これらのパーティション情報と Broker との対応関係もすべて維持されます。 by Zookeeper
-
プロデューサーの負荷分散: 同じトピック メッセージが分割されて複数のブローカーに分散されるため、プロデューサーは送信されたメッセージをこれらの分散ブローカーに合理的に分散する必要があります。
-
コンシューマのロード バランシング: プロデューサと同様に、Kafka のコンシューマも、複数のコンシューマが対応するブローカー サーバーからメッセージを合理的に受信できるようにロード バランシングを必要とします。コンシューマ グループには複数のコンシューマが含まれており、それぞれメッセージはグループ内の 1 つのコンシューマにのみ送信されます。異なるコンシューマ グループは、相互に干渉することなく、独自の特定のトピックの下でメッセージを消費します。
キーワードへの回答
Kafka のアーキテクチャを簡単に説明してください。 -
プロデューサー、コンシューマー、コンシューマー グループ、トピック、パーティション
##Kafka はプッシュ モードですか? プル モードですか? プッシュ/プル違いは何ですか?
-
Kafka プロデューサーはプッシュ モードを使用してメッセージをブローカーに送信し、コンシューマーはプル モードを使用して消費します。コンシューマが独自にオフセットを管理できるプル モードにより、読み取りパフォーマンスを提供できます
#Kafka はどのようにメッセージをブロードキャストしますか? 消費者グループ
Kafka のメッセージは正しいですか?
トピック レベルは順序付けされておらず、パーティションは順序付けされています
Kafka は読み取りと書き込みの分離をサポートしていますか?
サポートされていません。外部の読み取りおよび書き込みサービスを提供するのは Leader のみです。
Kafka はどのようにして高いデータ可用性を確保しますか?
コピー、確認、HW
Kafka における動物園の飼育員の役割は何ですか? #クラスター管理、メタデータ管理
トランザクションをサポートしていますか? 0.11 以降、トランザクションがサポートされ、「1 回だけ」実行できるようになりました。
パーティションの数は変更できますか?削減?
Kafka を使用した
問題
- Kafka にはどのようなコマンド ライン ツールがありますか?どちらを使用したことがありますか?
- Kafka プロデューサーの一般的な構成は何ですか?
- Kafka メッセージを整理するにはどうすればよいでしょうか?
- プロデューサー データ送信が失われないようにするにはどうすればよいですか?
- プロデューサーのパフォーマンスを向上させるにはどうすればよいですか?
- 同じグループ内のコンシューマーの数がパーツの数よりも多い場合、Kafka はそれをどのように処理しますか?
- 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 : zk サービスを開始します
-
#zookeeper-server-stop.sh: zk サービスを停止します
-
zookeeper-shell.sh: zk client
-
通常、
kafka-console-consumer.sh
および
kafka-console-Producer.sh スクリプトを使用して、Kafka の生成と使用をテストできます。
kafka-consumer-groups.sh はクラスター内のトピックを表示および管理できます。通常、
kafka-topics.sh は Kafka のコンシューマー グループの状況を表示するために使用されます。
Kafka プロデューサー
Kafka プロデューサーの通常のプロダクション ロジックには、次の手順が含まれます。
- プロデューサーを構成するクライアントパラメータの共通プロデューサーインスタンス。
- #送信するメッセージを作成します。 ############メッセージを送ります。
#プロデューサー インスタンスを閉じます。 Producer メッセージ送信のプロセスは次の図に示されており、- interceptorserializer
、
partitioner を経由する必要があります。
、最終的には、アキュムレータ
によってバッチでブローカーに送信されます。
プロデューサー
Kafka プロデューサには次の必須パラメータが必要です:
key.serializer:キーシリアライザーvalue.serializer:値シリアライザー-
共通パラメータ:
batch.num.messages
デフォルト値: 200 (非同期キックインの場合のみ、毎回のバッチ メッセージの数)。 -
request.required.acks
デフォルト値: 0、0 は、プロデューサーがリーダーからの確認を待つ必要がないことを意味します。1 は、リーダーがローカル ログへの書き込みを確認してすぐに確認する必要があることを意味します。-1 は、プロデューサーは、すべてのバックアップが完了した後に確認する必要があります。非同期モードでのみ機能します。このパラメータの調整は、データ損失と伝送効率の間のトレードオフです。データ損失には敏感ではないが、効率を重視する場合は、0 に設定することを検討できます。これにより、伝送効率が大幅に向上します。データ送信時のプロデューサー。
- #request.timeout.ms
デフォルト値: 10000、確認タイムアウト。
- partitioner.class
デフォルト値: kafka.Producer.DefaultPartitioner、kafka.Producer.Partitioner を実装する必要があります, キーに基づいてパーティション分割戦略を提供します。 同じ種類のメッセージを順番に処理する必要がある場合があるため、同じ種類のデータを同じパーティションに割り当てるように分散戦略をカスタマイズする必要があります。
- Producer.type
デフォルト値: sync、メッセージが同期的に送信されるか非同期的に送信されるかを指定します。 。非同期非同期バッチ送信には kafka.Producer.AyncProducer を使用し、同期同期には kafka.Producer.SyncProducer を使用します。同期送信と非同期送信は、メッセージ生成の効率にも影響します。
- #compression.topicデフォルト値: なし、メッセージ圧縮、デフォルトでは圧縮なし。他の圧縮方法には、「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 (プロデューサー キュー内の最大キャッシュ データ)時間、非同期のみ。
queue.buffering.max.message
- デフォルト値: 10000、プロデューサーによってキャッシュされるメッセージの最大数、非同期専用。
queue.enqueue.timeout.ms
デフォルト値: -1、キューがいっぱいの場合、0 は破棄されます。負の値はキューがいっぱいのときのブロック、正の値はキューがいっぱいのときのブロックの対応する時間です。非同期の場合。
Kafka Consumer
Kafka にはコンシューマ グループの概念があり、各コンシューマのみが消費できます割り当てられたパーティションからのメッセージ。各パーティションはコンシューマ グループ内の 1 つのコンシューマによってのみ消費されます。そのため、同じコンシューマ グループ内のコンシューマの数がパーティションの数を超えると、一部のコンシューマが表示されます。消費できないパーティションは割り当てられます。 。コンシューマ グループとコンシューマの関係を次の図に示します。
Kafka Consumer Client によるメッセージの消費には、通常、次の手順が含まれます。
- クライアントを構成してコンシューマを作成する
- トピックを購読する
- メッセージをプルして消費するそれ
- 消費変位の送信
- コンシューマ インスタンスを閉じる
Kafka の Consumer クライアントはスレッドアンセーフであるため、スレッドの安全性を確保し、消費パフォーマンスを向上させるために、Reactor に似たスレッド モデルを Consumer 側で使用してデータを消費できます。
Kafka コンシューマ パラメータ
- bootstrap.servers : 接続ブローカーのアドレス、
host: port
形式。
- group.id: コンシューマが属するコンシューマ グループ。
- key.deserializer: プロデューサの
key.serializer
、キーの逆シリアル化メソッドに対応します。
- value.deserializer: プロデューサの
value.serializer
、value の逆シリアル化メソッドに対応します。
- session.timeout.ms: コーディネーターの検出が失敗した時刻。デフォルトは 10 秒です。このパラメータは、ハートビートの有効期限と同様に、コンシューマ グループ (グループのメンバーである comSummer) がクラッシュをアクティブに検出する時間間隔です。
- auto.offset.reset: この属性は、コンシューマがオフセットなしでオフセットを読み取った場合、そのオフセットが無効であることを指定します (コンシューマは長期間有効期限が切れており、現在のオフセットは無効です)パーティションが古くなって削除された場合はどうすればよいですか? デフォルト値は最新で、最新のレコード (コンシューマーの開始後に生成されたレコード) からデータを読み取ることを意味します。もう 1 つの値は最も早いもので、これは次のことを意味します。部分シフト量が無効な場合、コンシューマは開始位置からデータの読み取りを開始します。
- enable.auto.commit: 変位を自動的に送信する場合はいいえ。
false
の場合は、プログラム内で変位を手動で送信する必要があります。 1 回限りのセマンティクスの場合は、オフセットを手動で送信するのが最善です。
- fetch.max.bytes: データの 1 回のプルの最大バイト数
- max.poll.records: 1 回のポーリング呼び出しで返されるメッセージの最大数。処理ロジックが非常に軽量な場合は、この値を適切に増やすことができます。ただし、
max.poll.records
個のデータは session.timeout.ms 以内に処理する必要があります。デフォルト値は 500
- request.timeout.ms: リクエスト応答の最大待機時間です。タイムアウト期間内に応答が受信されない場合、Kafka はメッセージを再送信するか、再試行回数を超えると直接失敗します。
Kafka Rebalance
Rebalance は本質的に、コンシューマ グループに属するすべてのコンシューマがそれぞれのコンシューマをどのように割り当てるかを規定するプロトコルです。パーティションがトピックにサブスクライブされました。たとえば、特定のグループの下に 20 人のコンシューマがあり、100 のパーティションを持つトピックをサブスクライブするとします。通常の状況では、Kafka は各コンシューマーに平均 5 つのパーティションを割り当てます。この割り当てプロセスはリバランスと呼ばれます。
リバランスはいつ行うべきですか?
これもよく言われる質問です。リバランスには 3 つのトリガー条件があります:
- グループ メンバーの変更 (新しいコンシューマがグループに参加する、既存のコンシューマが自発的にグループを離れる、または既存のコンシューマがクラッシュする) - 2 つの違い後で説明します) to)
- トピックにサブスクライブされたパーティションの数が変更されました
グループ内にパーティションを割り当てるにはどうすればよいですか?
Kafka は、デフォルトで、範囲とラウンドロビンという 2 つの割り当て戦略を提供します。もちろん、Kafka はプラグ可能な割り当て戦略を採用しており、独自のアロケーターを作成してさまざまな割り当て戦略を実装できます。
キーワードへの回答
- Kafka のコマンド ライン ツールとは何ですか?どちらを使用したことがありますか?
/bin
ディレクトリ、kafka クラスターの管理、トピックの管理、kafka の生成と消費
- Kafka プロデューサーの実行プロセス?インターセプター、シリアライザー、パーティショナー、アキュムレーター
- Kafka プロデューサーの一般的な構成は何ですか?ブローカー構成、ack 構成、ネットワークおよび送信パラメーター、圧縮パラメーター、ack パラメーター
- Kafka メッセージを順序どおりに保つにはどうすればよいですか? Kafka 自体はトピック レベルでは順序付けされておらず、パーティションでのみ順序付けされているため、処理順序を保証するために、パーティショナーをカスタマイズして、連続して処理する必要があるデータを同じパーティションに送信することができます
- プロデューサー データを損失なく確実に送信するにはどうすればよいですか? ack メカニズム、再試行メカニズム
- プロデューサーのパフォーマンスを向上させるにはどうすればよいですか?バッチ、非同期、圧縮
- 同じグループ内のコンシューマーの数がパーツの数よりも多い場合、Kafka はそれをどのように処理しますか?冗長パーツは役に立たない状態になり、データを消費しません
- #Kafka Consumer はスレッドセーフですか?安全ではない、シングルスレッド消費、マルチスレッド処理
- Kafka Consumer を使用してメッセージを消費するときのスレッド モデルについて教えてください。なぜこのように設計されているのでしょうか?プルと処理の分離
- Kafka Consumer の一般的な構成?ブローカー、ネットワークおよびプル パラメーター、ハートビート パラメーター
- Consumer はいつクラスターから追い出されますか?クラッシュ、ネットワーク異常、処理時間が長すぎる、送信ディスプレイスメント タイムアウト
- Consumer が参加または終了したときに Kafka はどのように反応しますか?リバランスの実行
- リバランスとは何ですか?いつリバランスが行われますか?トピックの変更、消費者の変更
高可用性とパフォーマンス
問題
- Kafka はどのようにして高可用性を確保しますか?
- Kafka の配信セマンティクス?
- Replica は何をしますか?
- AR、ISR どうしたの?
- リーダーとフラワーとは何ですか?
- Kafka の HW、LEO、LSO、LW などは何を表しますか?
- Kafka は優れたパフォーマンスを確保するために何をしましたか?
#パーティションとレプリカ
分散データ システムでは、通常、システムの処理能力を向上させるためにパーティションが使用され、データの高可用性を確保するためにレプリカが使用されます。マルチパーティショニングとは、同時に処理できる機能を意味し、複数のコピーのうち 1 つだけがリーダーとなり、残りはフォロワー コピーになります。リーダー コピーのみが外部の世界にサービスを提供できます。複数のフォロワー コピーは通常、リーダー コピーとは異なるブローカーに保存されます。このメカニズムにより高可用性が実現され、特定のマシンがハングアップすると、他のフォロワー コピーがすぐに「正常に戻り」、外部へのサービスの提供を開始できます。
フォロワー コピーが読み取りサービスを提供しないのはなぜですか?
この問題は本質的に、パフォーマンスと一貫性の間のトレードオフです。想像してみてください。フォロワーのコピーが外部の世界にもサービスを提供したらどうなるでしょうか?まず、パフォーマンスは確実に向上します。しかし同時に、さまざまな問題も発生します。データベース トランザクションにおけるファントム リードとダーティ リードに似ています。たとえば、データを Kafka トピック a に書き込む場合、コンシューマ b はトピック a からのデータを消費しますが、コンシューマ b が読み取るパーティション コピーに最新のメッセージが書き込まれていないため、そのデータを消費できないことがわかります。このとき、別のコンシューマcはリーダーコピーを消費するため、最新のデータを消費することができる。 Kafka は、WH と Offset の管理を使用して、Consumer が消費できるデータと現在書き込まれているデータを決定します。
リーダーのみが外部読み取りサービスを提供できるため、リーダーの選出方法
kafkaリーダー レプリカによって同期が維持されるレプリカは、ISR レプリカ セットに配置されます。もちろん、ISR コピー セットには必ずリーダー コピーが存在しますが、特殊な場合には、ISR コピー内にリーダーのコピーが 1 つだけ存在することもあります。リーダーが失敗すると、kakfa は飼育員を通じてこの状況を感知し、ISR コピー内の新しいコピーをリーダーとして選択し、外部の世界にサービスを提供します。しかし、これには別の問題があり、前述したように、ISR レプリカ セットにはリーダーしか存在しない可能性があり、リーダー レプリカが死ぬと ISR セットは空になります。このとき、unclean.leader.election.enable パラメーターが true に設定されている場合、Kafka は非同期のリーダーとなるレプリカ、つまり ISR レプリカ セットに含まれていないレプリカを選択します。
コピーが存在するとコピー同期の問題が発生します
Kafka は、割り当てられたすべてのレプリカ (AR) で使用可能なレプリカ リスト (ISR) を維持します。プロデューサーがブローカーにメッセージを送信すると、## に基づいてメッセージが同期されるまで待機する必要があるレプリカの数を決定します。 #ack 構成。成功した場合のみ、ブローカーは
ReplicaManager サービスを内部的に使用して、フラワーとリーダー間のデータ同期を管理します。
パフォーマンスの最適化
パーティションの同時実行性ディスクへの順次読み取りおよび書き込みページ キャッシュ: ページごとの読み取りおよび書き込み先をお読みください: Kafka は、メモリに消費されるメッセージを事前に読み取ります高パフォーマンスのシリアル化 (バイナリ)メモリ マッピングロックフリーのオフセット管理: 同時実行機能の向上Java NIO モデルバッチ: バッチ読み取り圧縮: メッセージ圧縮、ストレージ圧縮、ネットワークと IO オーバーヘッドの削減
#パーティション同時実行
一方で、異なるパーティションを異なるマシンに配置できるため、クラスターの利点を最大限に活用してマシン間の並列処理を実現できます。一方、パーティションは物理的にフォルダーに対応するため、同じノード上に複数のパーティションが存在する場合でも、同じノード上の異なるパーティションを異なるディスクドライブに配置するように構成して、ディスク間の並列処理を実現できます。複数のディスクの。
逐次読み取りおよび書き込み
Kafka の各パーティション ディレクトリ内のファイルは、同じサイズに均等に分割されます (デフォルトのファイル サイズは 500 MB です) 、手動で設定できる) データ ファイル、
各データ ファイルはセグメント ファイルと呼ばれ、各セグメントはデータを追加するために append を使用します。
キーワードを答える
方法Kafka は高可用性を保証しますか?
レプリカ、プロデューサーの確認応答、再試行、リーダーの自動選出、コンシューマーのセルフバランシングを通じてデータの高可用性を確保します
- # #Kafka の配信セマンティクス?
配信セマンティクスには通常、少なくとも 1 回 、
最大 1 回 、および
正確に 1 回 が含まれます。 Kafka は、ack 構成を通じて最初の 2 つを実装します。
- Replica は何をしますか?
データの高可用性の実現
- AR と ISR とは何ですか?
AR: 割り当てられたレプリカ。 AR は、トピックの作成後にパーティションが作成されるときに割り当てられるレプリカのセットであり、レプリカの数はレプリカ係数によって決まります。 ISR: 同期レプリカ。 Kafka の特に重要な概念は、リーダーと同期される AR 内のレプリカのセットを指します。 AR 内のレプリカは ISR に含まれていない可能性がありますが、リーダー レプリカは当然 ISR に含まれます。 ISR に関しては、面接でよく聞かれるもう 1 つの質問は、コピーが ISR に属するかどうかを判断する方法です。現在の判断は、フォロワーのレプリカの LEO がリーダーの LEO より遅れている時間が、ブローカー側のパラメーターplica.lag.time.max.ms の値を超えるかどうかに基づいています。それを超えると、レプリカは ISR から削除されます。
- Kafka の HW は何を表しますか?
最高水準。これは、コンシューマが読み取ることができるメッセージの範囲を制御する重要なフィールドです。通常のコンシューマは、ログ開始オフセットとハードウェア (排他的) の間のリーダー レプリカ上のすべてのメッセージを「表示」することしかできません。水面より上のメッセージは消費者には見えません。
- Kafka は優れたパフォーマンスを確保するために何をしましたか? #パーティションの同時実行性、ディスクへのシーケンシャル読み取りおよび書き込み、ページ キャッシュ圧縮、高パフォーマンスのシリアル化 (バイナリ)、メモリ マッピングのロックフリー オフセット管理、Java NIO モデル
この記事では、Kafka の実装の詳細とソース コード分析については触れませんが、Kafka は確かに優れたオープン ソース システムであり、多くのエレガントなアーキテクチャ設計とソース コード設計は学ぶ価値があります。このオープン ソース システムについて知ることは、アーキテクチャ設計能力、コーディング能力、パフォーマンスの最適化に非常に役立ちます。