インタビュー中に、特にカフカ関連の質問をするのが好きなインタビュアーが多いことがわかりました。1台のマシンのスループットが100,000ミリ秒の遅延で、カフカがビッグデータの分野で唯一のメッセージキューの王者である理由を理解するのは難しくありません。この種の自然な分散メッセージキューを愛することができないのは誰ですか？
最近のインタビューで、インタビュアーはレジュメの項目にカフカが書かれているのを見て、カフカに直接尋ね、基本的に他の質問はしませんでした。インタビュアーのカフカの8つの連続した質問を見てみましょう。
（以下の回答は面接後にまとめたものであり、実際の面接では回答の約3分の1しか回答していません）
1.なぜカフカを使うのですか？
バッファリングとピーククリッピング：アップストリームデータのバーストがある場合、ダウンストリームがそれを処理できないか、ダウンストリームに冗長性を確保するのに十分なマシンがない可能性があります。Kafkaは中間のバッファとして機能し、Kafkaとダウンストリームにメッセージを一時的に保存できます。サービスは、独自のペースでゆっくりと処理できます。
デカップリングとスケーラビリティ：プロジェクトの開始時に、特定の要件を決定することはできません。メッセージキューは、重要なビジネスプロセスを分離するためのインターフェイスレイヤーとして使用できます。規則に従うだけで、データプログラミングの拡張機能を利用できます。
冗長性：1対多のアプローチを使用できます。プロデューサーはメッセージを公開します。メッセージは、複数の無関係なビジネスで使用するために、複数のサブスクリプショントピックサービスで使用できます。
堅牢性：メッセージキューはリクエストを蓄積できるため、消費者向けビジネスが短時間で終了しても、メインビジネスの通常の運用に影響を与えることはありません。
非同期通信：多くの場合、ユーザーはメッセージをすぐに処理する必要はありません。メッセージキューは、ユーザーがメッセージをキューに入れることを可能にする非同期処理メカニズムを提供しますが、すぐには処理しません。必要な数のメッセージをキューに入れ、必要に応じて処理します。
2. Kafkaによって消費されたメッセージをどのように消費しますか？
Kafka消費メッセージのオフセットはzookeeperで定義されています。Kafkaメッセージを繰り返し消費する場合は、オフセットチェックポイントポイント（n）をredisに記録できます。メッセージを繰り返し消費する場合は、redisでチェックポイントポイントを読み取ります。動物園の飼育係のオフセットをリセットして、メッセージを繰り返し消費するという目的を達成できるようにします
3. Kafkaのデータはディスクまたはメモリに保存されていますか？なぜ速度が速いのですか？
Kafkaはディスクストレージを使用します。
速度が速い理由は次のとおりです。
- シーケンシャル書き込み：ハードディスクは機械的な構造であるため、読み取りと書き込みのそれぞれがアドレス指定されます->書き込み。アドレス指定は「機械的なアクション」であり、時間がかかります。そのため、ハードドライブはランダムI / Oを「嫌い」、シーケンシャルI / Oを好みます。Kafkaは、ハードディスクの読み取りと書き込みの速度を上げるために、シーケンシャルI / Oを使用します。
- メモリマップファイル：64ビットオペレーティングシステムは通常、20Gデータファイルを表すことができます。その動作原理は、オペレーティングシステムのページを直接使用して、ファイルの物理メモリへの直接マッピングを実現することです。マッピングが完了すると、物理メモリでの操作がハードディスクに同期されます。
- Kafkaの効率的なファイルストレージ設計：Kafkaは、トピック内の大きなパーティションファイルを複数の小さなファイルセグメントに分割します。複数の小さなファイルセグメントを使用すると、消費されたファイルを定期的にクリアまたは削除して、ディスク使用量を減らすことができます。インデックス情報
により、メッセージをすばやく見つけて、応答のサイズを決定できます。すべてのインデックスメタデータをメモリ（メモリマップファイル）にマッピングすることにより、
セグメントファイルのIOディスク操作を回避できます。インデックスファイルをまばらに保存することで、インデックスファイルのメタデータが占めるスペースを大幅に削減できます。
注意：
- クエリの効率を解決するKafkaの方法の1つは、データファイルをセグメント化することです。たとえば、100個のメッセージがあり、それらのオフセットは0から99です。データファイルが5つのセグメントに分割され、最初のセグメントが0〜19、2番目のセグメントが20〜39というように、各セグメントが個別のデータファイルに配置され、データファイルの名前がセグメントの小さなオフセットに基づいているとします。このように、指定されたオフセット
でメッセージを検索する場合、バイナリ検索を使用して、メッセージがどのセグメントにあるかを見つけることができます。- データファイルデータファイルセグメンテーションのインデックスを作成すると、より小さなデータファイルでオフセットに対応するメッセージを見つけることができますが、オフセットに対応するメッセージを見つけるには、シーケンシャルスキャンが必要です。
検索効率をさらに向上させるために、Kafkaはセグメント化されたデータファイルごとにインデックスファイルを作成します。ファイル名はデータファイル名と同じですが、ファイル拡張子は.indexです。
4. Kafkaデータを失わないようにするにはどうすればよいですか？
3つのポイントで、1つはプロデューサー側、コンシューマー側、ブローカー側です。
- プロデューサーデータの損失なし
Kafkaのackメカニズム：Kafkaがデータを送信するとき、メッセージが正常に受信できることを確認するために、メッセージが送信されるたびに確認フィードバックメカニズムがあり、ステータスは0、1、-1です。
同期モードの場合：
ackが0に設定されているため、非常に危険です。通常、0に設定することはお勧めしません。1に設定しても、リーダーがダウンするとデータが失われます。したがって、生産終了データが失われないように厳密に確認する場合は、-1に設定できます。
非同期モードの場合：
ackのステータスも考慮されます。さらに、非同期モードのバッファーがあり、これを介して制御データが送信されます。制御には、時間しきい値とメッセージ数の2つの値があります。バッファがいっぱいでデータが送信されていない場合は、バッファをすぐにクリアするかどうかを設定するオプションがあります。-1に設定すると、永続的にブロックできます。これは、データが生成されなくなったことを意味します。非同期モードでは、-1に設定されていても。また、kill -9など、プログラマーの非科学的な操作によって操作データが失われる可能性もありますが、これは特別な例外です。
注：
ack = 0：プロデューサーは、ブローカー同期の完了の確認を待たずに、次の（バッチ）メッセージを送信し続けます。
ack = 1（デフォルト）：プロデューサーは、リーダーがデータを正常に受信して確認を取得するのを待ってから、次のメッセージを送信します。
ack = -1：プロデューサーは、フォロワーから確認を得た後にのみ、次のデータを送信します。
- 消費者データの損失なし
オフセットコミットは、データが失われないようにするために使用されます。Kafkaは、各消費のオフセット値を記録します。次回消費を続けると、最後のオフセットで消費を継続します。
オフセット情報は、kafkaのバージョン0.8より前にzookeeperに保存され、バージョン0.8以降にトピックに保存されます。操作中にコンシューマーが電話を切った場合でも、再起動時にオフセット値が検出され、以前の消費メッセージが検出されます。オフセット情報が書き込まれるとき、消費が完了した後にすべてのメッセージが書き込まれるわけではないため、場所、次に消費。この状況では繰り返し消費が発生する可能性がありますが、メッセージは失われません。
唯一の例外は、
KafkaSpoutConfig.bulider.setGroupidをプログラムで元々異なる機能を実行した2つのコンシューマーグループに設定したときに、KafkaSpoutConfig.bulider.setGroupidを同じgroupidに設定した場合です。この状況では、2つのグループが同じデータを共有します。グループAはパーティション1とパーティション2のメッセージを消費し、グループBはパーティション3のメッセージを消費します。このようにして、各グループによって消費されたメッセージは失われ、不完全になります。各グループがメッセージデータの排他的共有を持つことを保証するために、groupidを繰り返さないでください。
- Kafkaクラスター内のブローカーのデータは失われません
通常、ブローカー内の各パーティションのレプリケーション（レプリカ）の数を設定します。プロデューサーが書き込むときは、最初に配布戦略（パーティションごと、キーごと、ポーリングなし）に従ってリーダーに書き込みます。 、フォロワー（レプリカ）はデータをリーダーと同期するため、バックアップを使用すると、メッセージデータが失われないようにすることもできます。
5.データ収集にkafkaを選択する理由
取得レイヤーは、主にFlume、Kafka、およびその他のテクノロジーを使用できます。
Flume：Flumeはパイプラインフローメソッドであり、多くのデフォルト実装を提供し、ユーザーがパラメーターを介して展開し、APIを拡張できるようにします。
Kafka：Kafkaは耐久性のある分散メッセージキューです。Kafkaは非常に用途の広いシステムです。多くのプロデューサーと多くのコンシューマーが複数のトピックを共有することができます。
対照的に、FlumeはHDFSとHBaseにデータを送信するために設計された特別なツールです。HDFS用に特別に最適化されており、Hadoopのセキュリティ機能を統合しています。
したがって、Clouderaは、データが複数のシステムで消費される場合はKafkaを使用することをお勧めします。データがHadoopで使用されるように設計されている場合は、Flumeを使用してください。
6. Kafkaを再起動すると、データが失われますか？
- Kafkaはデータをディスクに書き込み、通常、データは失われません。
- ただし、Kafkaを再起動する過程で、メッセージを消費する消費者がいる場合、Kafkaにオフセットを送信する時間がない場合、データが不正確になる可能性があります（損失または繰り返し消費）。
7. Kafkaがダウンした場合の解決方法は？
- まず、ビジネスが影響を受けるかどうかを検討します
Kafkaがダウンしています。最初に検討する必要があるのは、提供されるサービスがダウンマシンの影響を受けるかどうかです。サービスが提供されている場合、クラスターの耐災害メカニズムが実装されていれば、これについて心配する必要はありません。 。
- ノードのトラブルシューティングとリカバリ
クラスターのノードを復元するための主な手順は、ログ分析を通じてノードのダウンタイムの原因を確認し、問題を解決してノードを再度復元することです。
8. Kafkaが読み取り/書き込み分離をサポートしないのはなぜですか？
カフカでは、メッセージを書くプロデューサーとメッセージを読む消費者の操作はすべてリーダーコピーと相互作用し、マスターの書き込みと読み取りの生産と消費のモデルを実現します。マスター-書き込み-スレーブの読み取りには2つの明らかな欠点があるため、
Kafkaはマスター-書き込み-スレーブの読み取りをサポートしていません。
データ整合性の問題：マスターノードからスレーブノードへのデータの遅延時間枠があります。この時間枠により、マスターノードとスレーブノード間でデータの不整合が発生します。ある時点で、マスターノードとスレーブノードの両方のAデータの値がXになり、マスターノードのAの値がYに変更され、変更がスレーブノードに通知される前に、アプリケーションはスレーブノードのAデータを読み取ります。の値は最新のYではないため、データの不整合の問題が発生します。
遅延の問題：Redisのようなコンポーネントの場合、マスターノードからスレーブノードへの同期にデータを書き込むプロセスは、ネットワーク→マスターノードメモリ→ネットワーク→スレーブノードメモリの段階を経る必要があります。プロセス全体には一定の時間がかかります。Kafkaでは、マスタースレーブ同期はRedisよりも時間がかかり、ネットワーク→マスターノードメモリ→マスターノードディスク→ネットワーク→スレーブノードメモリ→スレーブノードディスクの段階を経る必要があります。遅延の影響を受けやすいアプリケーションの場合、マスター書き込みとスレーブ読み取りの機能はあまり適していません。
そして、kafkaのマスター-ライトマスター-リーダーの利点はたくさんあります：
- コードの実装ロジックを簡素化し、エラーの可能性を減らすことができます。
- マスター書き込みおよびスレーブ読み取りと比較して、負荷の細かさが洗練され、均等に分散されているため、負荷のパフォーマンスが向上するだけでなく、ユーザーも制御できます。
- 遅延効果はありません。
- コピーが安定している場合、データの不整合はありません。