カフカの11の致命的な質問

[[431290]]

私は何一つ得意ではないのですが、小説を読むのが一番得意です。ほら、いい記事を書いたよ。

最近、記事のカタログを整理しました。ずっと前に、ある兄弟が以前の記事が見つからないと言っていたのですが、整理するのが面倒だったのです。今、慎重に整理してみると、途中で書き残した記事があることに気づきました。時間をかけて完成させました。おそらく、質問が多すぎてどこから入手すればよいかを考えるのが難しかったからでしょうか???

記事ディレクトリを見つけたい場合は、公式アカウントのメニューバーの中央を見てください。これにより、今後は皆様にとってさらに便利になります。

カフカについてのあなたの理解を教えてください

Kafka はストリーミングデータ処理プラットフォームです。メッセージングシステムの機能と、リアルタイムのストリーミングデータ処理および分析機能を備えていますが、メッセージキューシステムとして使用することが多いです。

分かりやすいように3つの層に分けると、大きく分けて以下の3つの層になります。

最初のレイヤーは Zookeeper であり、登録センターに相当します。 Kafka クラスターのメタデータの管理とクラスターの調整を担当します。各 Kafka サーバーが起動すると、Zookeeper に接続し、Zookeeper に自身を登録します。

2 番目のレイヤーは Kafka のコアレイヤーであり、Kafka の多くの基本概念が含まれています。

レコード: メッセージを表す

トピック: メッセージはトピック別に整理されます。トピックはメッセージの分類として理解できます。

プロデューサー: メッセージの送信を担当するプロデューサー

消費者: メッセージの消費を担当する消費者

ブローカー: kafka サーバー

パーティション: トピックは複数のパーティションで構成されます。通常、各パーティションのメッセージは順番に読み取られます。異なるパーティションの順序は保証されません。パーティションは、データシャーディングメカニズムと呼ばれることが多いものです。主な目的はシステムのスケーラビリティを向上させることです。パーティショニングにより、メッセージの読み取りと書き込みを複数の異なるノードに負荷分散できます。

リーダー/フォロワー: パーティションのレプリカ。高可用性を確保するために、各パーティションにはいくつかのレプリカが存在します。各パーティションには、データの読み取りと書き込みを担当するリーダーマスターレプリカが存在します。フォロワースレーブレプリカは、リーダーレプリカとのデータの同期を維持する役割のみを担い、外部サービスは提供しません。

オフセット: オフセット。パーティション内の各メッセージには、時間順に増加するシーケンス番号が付けられます。このシーケンス番号がオフセットです。

コンシューマーグループ: コンシューマーグループは複数のコンシューマーで構成されます。グループ内の 1 つのコンシューマーのみがパーティションからのメッセージを消費します。

コーディネーター: コーディネーターは、主にコンシューマーグループのパーティションの割り当てと再バランス操作を担当します。

コントローラー: コントローラーは、実際には Kafka クラスター全体を調整および管理するブローカーです。パーティションリーダーの選出、トピック管理などを担当します。Zookeeper で最初に一時ノード/コントローラーを作成した人がコントローラーになります。

3 番目のレイヤーはストレージレイヤーで、Kafka のコアデータを保存するために使用されます。これらのデータはすべて、最終的にログの形式でディスクに書き込まれます。

メッセージキューモデルをご存知ですか? Kafka はこれら 2 つのモデルをどのようにサポートしますか?

従来のメッセージキューシステムは、次の 2 つのモデルをサポートしています。

ポイントツーポイント: メッセージは 1 つのコンシューマーによってのみ消費され、消費後には削除されます。
パブリッシュとサブスクライブ: ブロードキャストモードと同等で、メッセージはすべてのコンシューマーが消費できる

前述のように、Kafka は実際には Consumer Group を通じて両方のモデルをサポートしています。

すべてのコンシューマーがグループに属しており、メッセージを同じグループ内の 1 つのコンシューマーのみが使用できる場合は、ポイントツーポイントモードになります。

各コンシューマーが個別のグループである場合、それはパブリッシュ/サブスクライブモデルです。

実際、Kafka はコンシューマーをグループ化することでこれら 2 つのモデルを柔軟にサポートします。

Kafka の通信プロセスについて説明していただけますか?

まず、Kafka ブローカーが起動すると、ブローカー自身の ID を Zookeeper に登録します (一時ノードを作成します)。この ID は設定することも、自動的に生成することもできます。同時に、Zookeeper の brokers/ids パスをサブスクライブします。新しいブローカーが参加または退出すると、すべてのブローカーの最新情報を取得できます。
プロデューサーが起動すると、bootstrap.servers が指定されます。指定されたブローカーアドレスを通じて、Kafka はこれらのブローカーとの TCP 接続を確立します (通常、すべてのブローカーサーバーアドレスを構成する必要はありません。そうでない場合、Kafka は構成されたすべてのブローカーとの TCP 接続を確立します)。
任意のブローカーに接続した後、メタデータ情報 (トピック、パーティション、レプリカ、リーダーレプリカなど) を取得するためのリクエストを送信します。
その後、すべてのブローカーとのTCP接続が作成されます。
次にメッセージを送信するプロセスです
プロデューサーと同様に、コンシューマーも bootstrap.servers プロパティを指定し、ブローカーを選択して TCP 接続を作成し、コーディネーターが配置されているブローカーを見つけるための要求を送信します。
次に、コーディネーターブローカーとのTCP接続を作成してメタデータを取得します。
パーティションリーダーノードが配置されているブローカーノードとの接続を作成します。
ついにメッセージの消費を開始

では、メッセージを送信するときにパーティションをどのように選択するのでしょうか?

主な方法は 2 つあります。

ポーリング、メッセージは順番に異なるパーティションに送信されます
ランダム、ランダムにパーティションに送信

メッセージにキーが指定されている場合、メッセージキーはハッシュされ、パーティションの数を法として、どのパーティションに該当するかが決定されます。したがって、同じキーを持つメッセージは常に同じパーティションに送信され、これはメッセージパーティション順序と呼ばれることがよくあります。

非常に一般的なシナリオは、注文メッセージと支払いメッセージを順序どおりにしたい場合です。そのため、注文 ID をキーとして使用してメッセージを送信すると、パーティション順序の目的が達成されます。

キーが指定されていない場合は、デフォルトのラウンドロビン負荷分散戦略が実行されます。たとえば、最初のメッセージは P0 に、2 番目のメッセージは P1 に、3 番目のメッセージは再び P1 に送信されます。

さらに、特定のビジネスシナリオや要件では、Partitioner インターフェイスを実装し、configure メソッドと partition メソッドを書き換えることで、カスタムパーティション分割を実現することもできます。

では、なぜパーティショニングが必要だと思いますか?メリットは何ですか?

この問題は非常に簡単です。パーティショニングがない場合、メッセージを送信したりデータを書き込んだりできるのは 1 つのノードのみです。この場合、このサーバーノードのパフォーマンスがどれだけ優れていても、最終的にはサポートできなくなります。

実際、すべての分散システムはこの問題に直面しています。メッセージを受信した後にデータを分割するか、事前にデータを分割します。カフカは前者を選びます。パーティショニングにより、データを異なるノードに均等に分散できます。

パーティショニングにより、負荷分散と水平拡張機能が実現します。

メッセージを送信する際に、パーティションの数に応じて異なる Kafka サーバーノードに送信できるため、同時メッセージ書き込みのパフォーマンスが向上します。メッセージを消費する場合、それらはコンシューマーにバインドされ、異なるノードの異なるパーティションからのメッセージを消費できるため、メッセージの読み取り機能が向上します。

もう 1 つは、パーティションによってレプリカが導入されることです。冗長レプリカにより、Kafka の高可用性と耐久性が保証されます。

消費者グループと消費者の再調整について詳しく説明していただけますか?

Kafka のコンシューマーグループは、トピック topics からのメッセージをサブスクライブします。一般的に言えば、コンシューマーの数はすべてのトピックパーティションの数と一致する必要があります (たとえば、1 つのトピックが使用されますが、実際には複数のトピックをサブスクライブできます)。

コンシューマーの数がパーティションの数より少ない場合、複数のパーティションからのメッセージを消費するコンシューマーが 1 つ存在する必要があります。

消費者の数がパーティションの数を超えると、消費するパーティションを持たない消費者が必然的に存在します。

したがって、消費者団体の利点については上記で述べました。一方では、複数のメッセージモデルをサポートできます。一方、消費者とパーティション間の消費関係に基づいて、水平方向の拡張と縮小をサポートできます。

コンシューマーがパーティションをどのように消費するかがわかれば、明らかに問題が生じます。コンシューマーが消費するパーティションはどのように割り当てられるのでしょうか?先に参加する消費者がいる場合はどうすればいいでしょうか?

旧バージョンの再バランス処理は主に ZK リスナーによってトリガーされ、各コンシューマークライアントがパーティション割り当てアルゴリズムを独自に実行します。

コーディネータを通じて新バージョンが完成します。新しいコンシューマーが参加するたびに、パーティション割り当てを取得するためにコーディネータにリクエストが送信されます。このパーティション割り当てのアルゴリズムロジックはコーディネータによって完了されます。

リバランスとは、新しい消費者が参加する状況を指します。たとえば、最初はメッセージを消費するコンシューマー A のみが存在します。しばらくすると、消費者 B と C が参加します。この時点で、パーティションを再割り当てする必要があります。これはリバランスであり、リバランスとも呼ばれます。ただし、再バランス調整プロセスは GC STW と非常によく似ており、コンシューマーグループ全体の動作が停止し、再バランス調整期間中はメッセージを送信できなくなります。

さらに、コンシューマーとパーティションの合計数の間には結合関係があるため、これが再バランス調整が発生する唯一のケースではありません。前述のように、コンシューマーの数は、すべてのトピックのパーティションの合計数と同じである必要があります。

その後、コンシューマーの数、トピックの数 (通常のサブスクリプションに使用されるトピックなど)、またはパーティションの数のいずれかが変更されると、再バランスがトリガーされます。

リバランスのプロセスについてお話ししましょう。

再バランス調整メカニズムは、コンシューマーとコーディネータ間のハートビートに依存して維持されます。コンシューマーには、定期的にコーディネータにハートビートを送信するための独立したスレッドがあります。ハートビートの送信間隔は、パラメータ heartbeat.interval.ms によって制御できます。

各コンシューマーが初めてグループに参加する場合、コーディネーターに JoinGroup リクエストを送信します。このリクエストを最初に送信したコンシューマーが「グループ所有者」になり、コーディネーターはグループ所有者にグループメンバーのリストを返します。
グループ所有者はパーティション割り当て戦略を実行し、割り当て結果を SyncGroup 要求を通じてコーディネーターに送信します。コーディネータはパーティション割り当ての結果を受け取ります。
グループ内の他のメンバーもコーディネーターに SyncGroup を送信し、コーディネーターは各コンシューマーのパーティション割り当てでそれに応答します。

では、パーティション割り当て戦略について詳しく教えていただけますか?

主な割り当て戦略は 3 つあります。

範囲

どのように翻訳したらよいか分かりませんが、これがデフォルトの戦略です。一般的な意味はパーティションをソートすることであり、ソート度が高いパーティションにはより多くのパーティションを割り当てることができます。

たとえば、パーティションが 3 つあり、コンシューマー A の方がランクが高いため、2 つのパーティション P0\P1 に割り当てることができますが、コンシューマー B は 1 つのパーティション P2 にのみ割り当てることができます。

パーティションが 4 つある場合は、そのうちの 2 つに割り当てられます。

ただし、この割り当て戦略にはいくつか小さな問題があります。トピックに基づいてパーティションを割り当てるため、コンシューマーグループが複数のトピックをサブスクライブすると、パーティションの割り当てが不均衡になる可能性があります。

たとえば、下の図では、2 つのトピックの P0\P1 が両方とも A に割り当てられているため、A には 4 つのパーティションがあり、B には 2 つしかありません。このようなトピックがさらに多い場合、不均衡はさらに深刻になります。

ラウンドロビン

これはよく「世論調査」と呼ばれます。これは比較的単純なので、絵を描かなくても簡単に理解できます。

これにより、すべてのトピックに基づいてラウンドロビン割り当てが実行され、範囲にトピックがさらに存在する場合にパーティション割り当ての不均衡の問題は発生しません。

P0->A、P1->B、P1->A。。。等々

スティッキー

これは文字通り「粘着性のある戦略」を意味し、おおよそその通りの意味です。主な考慮事項は、バランスの取れた割り当てを維持しながら、パーティション割り当てに小さな変更を加えることです。

たとえば、P0\P1 が以前にコンシューマー A に割り当てられていた場合は、次回はそれを A に割り当てようとします。

これの利点は、接続を再利用できることです。メッセージを消費するには、常にブローカーに接続する必要があります。前回割り当てたパーティションを保持できる場合は、作成された接続を頻繁に破棄する必要はありません。

来て！メッセージの信頼性を確保するにはどうすればよいでしょうか?

基本的に、メッセージの信頼性の保証を3つの側面から説明する必要があります（より包括的かつ完璧になるように）

プロデューサーが送ったメッセージは失われます

Kafka は、結果に関係なく送信、同期して送信、非同期で送信という 3 つの一般的な方法でもメッセージを送信する 3 つの方法をサポートしています。基本的にすべてのメッセージキューはこのように動作します。

送信して忘れる、結果に関係なく、送信メソッドを直接呼び出します。自動再試行をオンにすることもできますが、メッセージが失われる可能性は確実にあります。
同期送信はFutureオブジェクトを返すので、送信結果を確認して処理することができます。
非同期でメッセージを送信し、それに応じて結果を処理するコールバック関数を指定します。

安全のため、通常はコールバックを使用した非同期送信を使用してメッセージを送信し、メッセージの送信に失敗した場合に継続的に再試行するようにパラメータを設定します。

acks=all、このパラメータは 0|1|all として設定できます。

0 は、サーバーの応答に関係なくプロデューサーがメッセージを書き込むことを意味します。メッセージはまだネットワークバッファー内に残っていて、サーバーがメッセージをまったく受信していない可能性があるため、メッセージは当然失われます。

1 は、少なくとも 1 つのレプリカがメッセージを受信した場合にのみ、メッセージが成功したと見なされることを意味します。レプリカが 1 つある場合は、それがクラスターのリーダーレプリカである必要があります。ただし、リーダーレプリカが配置されているノードがダウンし、フォロワーがメッセージを同期しない場合は、メッセージは失われます。

すべてが構成されている場合、メッセージが成功したと見なされるためには、すべての ISR が正常に書き込まれる必要があります。この場合、すべての ISR のすべてのコピーが失敗した場合にのみメッセージが失われます。

retries=N に非常に大きな値を設定すると、メッセージが失敗した後もプロデューサーが再試行を続けることができます。

カフカ自身のメッセージは失われている

Kafka は PageCache を通じてメッセージを非同期的にディスクに書き込むため、メッセージが失われる可能性が依然として残ります。

したがって、Kafka が失われないようにパラメータを設定します。

replication.factor=N の場合、少なくとも 2 つ以上のレプリカが存在するように、比較的大きな値を設定します。

min.insync.replicas=N は、メッセージが正常に書き込まれたとみなされる度合いを表します。少なくとも 1 つ以上のレプリカがメッセージに正常に書き込まれるようにするには、1 より大きい数値を設定します。

unclean.leader.election.enable=false の場合、この設定は、完全に同期されていないパーティションレプリカはリーダーレプリカになることができないことを意味します。これが事実であれば、リーダーと完全に同期されていないレプリカがリーダーになった後に、メッセージが失われるリスクが生じます。

消費者へのメッセージは失われた

消費者損失の可能性は比較的単純です。業務処理が成功したら、変位の自動送信をオフにして、手動送信に変更するだけです。

再バランス調整が発生すると、コンシューマーは最後に送信されたオフセットを読み取りますが、デフォルトの自動送信は 5 秒ごとに 1 回であるため、重複した消費やメッセージの損失が発生します。

enable.auto.commit=false、手動コミットに設定します。

考慮する必要がある別のパラメータもあります。

auto.offset.reset=earliest、このパラメータは、送信するオフセットがない場合、またはブローカーにオフセットが存在しない場合にコンシューマーがどのように処理するかを示します。最も早いとは、パーティションの先頭から読み取ることを意味します。メッセージは繰り返し読み取られますが、失われることはありません。消費者として、私たちは通常、自分自身で冪等性を確保する必要があります。別の種類の latest はパーティションの最後から読み取ることを意味しますが、その結果メッセージが失われる可能性があります。

これらのパラメータ設定を組み合わせることで、メッセージが失われることがなくなり、信頼性が確保されます。

さて、レプリカとその同期の仕組みについてお話ししましょう。

前述したように、Kafka レプリカはリーダーレプリカとフォロワーレプリカ、つまりプライマリレプリカとスレーブレプリカに分かれています。 MySQL などの他のレプリカとは異なり、Kafka では、リーダーレプリカのみが外部にサービスを提供し、フォロワーレプリカはデータの冗長性と災害復旧機能としてリーダーとデータを同期させるだけです。

Kafka では、すべてのレプリカのセットを AR (Assigned Replicas) と呼び、リーダーレプリカと同期されているレプリカのセットを ISR (InSyncReplicas) と呼びます。

ISR は動的なセットであり、このセットのメンテナンスは、フォロワーレプリカがリーダーレプリカより遅れる最大時間を表す replica.lag.time.max.ms パラメータによって制御されます。デフォルト値は 10 秒です。したがって、フォロワーレプリカがリーダーレプリカより 10 秒以上遅れていない限り、リーダーと同期していると見なすことができます (単純に同期時間差と考えることもできます)。

レプリカ間の同期には、他に 2 つの重要な概念があります。

HW (ハイウォーターマーク): ハイウォーターマークはレプリケーションポイントとも呼ばれ、レプリカ間の同期の場所を示します。下の図に示すように、0 ～ 4 個の緑色のメッセージは、レプリカ間で同期されたコミット済みメッセージを示します。消費者はこれらのメッセージを閲覧し、消費することができます。 4 ～ 6 個の黄色のメッセージはコミットされていないメッセージを示しており、レプリカ間で同期されていない可能性があります。これらのメッセージは消費者には見えません。

LEO (ログ終了オフセット): 次に書き込まれるメッセージのオフセット

どうやって

レプリカ間の同期プロセスは、HW と LEO の更新に依存します。値の変化は、レプリカ同期メッセージのプロセスを示すために使用されます。緑はリーダーレプリカを表し、黄色はフォロワーレプリカを表します。

まず、プロデューサーはリーダーにデータを書き込み続けます。この時点で、リーダーの LEO は 10 に達している可能性がありますが、HW はまだ 0 です。2 つのフォロワーはリーダーにデータの同期を要求しますが、その値は両方とも 0 です。

その後、メッセージはまだ書き込まれており、リーダーの LEO 値が再び変更され、2 人のフォロワーも独自のメッセージをプルして独自の LEO 値を更新しますが、この時点ではリーダーの HW は変更されません。

このとき、フォロワーはリーダーから再度データを取得します。このとき、リーダーは自身の HW 値を更新し、フォロワーの中で最小の LEO 値を取得して更新します。

その後、リーダーは自身の HW をフォロワーに応答し、フォロワーは自身の HW 値を更新します。メッセージを再度取得するため、LEO が再度更新され、プロセスは次のように続行されます。

Kafka の新しいバージョンが Zookeeper を廃止した理由をご存知ですか?

この質問には、2つの側面から答えることができると思います。

まず、運用・保守の複雑さという観点から言うと、Kafka 自体は分散システムであり、その運用・保守は既に非常に複雑です。さらに、別の ZK に大きく依存する必要があり、コストと複雑さの点で大きな負荷がかかります。

第二に、パフォーマンスの問題を考慮する必要があります。たとえば、以前の送信操作と移動操作はすべて ZK に保存されていましたが、ZK は実際にはこのような高頻度の読み取り、書き込み、更新操作には適しておらず、ZK クラスターのパフォーマンスに重大な影響を与えます。この点に関して、新しいバージョンでは、Kafka はメッセージの形式での変位の送信と保存も処理します。

さらに、Kafka はメタデータ管理とクラスター調整を実装するために ZK に大きく依存しています。クラスターが大きく、トピックとパーティションの数が多い場合、ZK クラスターのメタデータが多すぎてクラスターが過負荷になり、多くのウォッチの遅延や損失に直接影響します。

さて、誰もが尋ねる最後の質問は、なぜ Kafka は高速なのかということです。

おい、もう飽きたよ、何度も繰り返して言ったからね！主に3つの側面があります。

シーケンシャルIO

Kafka は、メッセージをパーティションに追加方式で書き込みます。つまり、ランダムに書き込むのではなく、ディスクに順番に書き込みます。この速度は通常のランダム IO よりもはるかに高速であり、ネットワーク IO の速度とほぼ同等です。

ページキャッシュとゼロコピー

メッセージデータを書き込むとき、Kafka は mmap メモリマッピングを使用します。すぐにディスクに書き込むのではなく、オペレーティングシステムのファイルキャッシュ PageCache を使用して非同期的に書き込むため、メッセージの書き込みパフォーマンスが向上します。さらに、メッセージを消費するときに、sendfile を通じてゼロコピーが実現されます。

mmap と sendfile ゼロコピーについて詳しく書きましたので、こちらでお読みください: Alibaba 第 2 回インタビュー: mmap とは何ですか?

バッチ処理と圧縮

Kafka はメッセージを送信するときに、メッセージを 1 つずつ送信するのではなく、複数のメッセージを 1 つのバッチにマージして処理し、送信します。メッセージの消費についても同様で、一度に大量のメッセージをプルして消費します。

さらに、プロデューサー、ブローカー、コンシューマーはすべて最適化された圧縮アルゴリズムを使用します。メッセージの送受信に圧縮を使用すると、ネットワーク転送のオーバーヘッドが削減され、ブローカーストレージで圧縮を使用すると、ディスクストレージ領域が削減されます。

私は艾小仙です。数日後に誰かを批判する準備をするつもりです。

<<: エッジコンピューティングが企業のセキュリティ構築に与える影響と動向

>>: クラウドベースのビデオ監視の準備はできていますか?