Kafka とは何ですか?知りたいですか？

あなたはプログラマーで、2 つのサービス A と B を管理しているとします。サービス B は 1 秒あたり 100 件のメッセージしか処理できませんが、サービス A は 1 秒あたり 200 件のメッセージを送信します。サービス B はそれを処理できず、数分以内に圧倒されてしまいます。そこで質問なのですが、B が負担をかけずに A のメッセージを処理できるようにする方法はあるのでしょうか?もちろんありますよ。中間層を追加することで解決できない問題はありません。ある場合は、別のレイヤーを追加します。今回追加する中間層はメッセージキューKafkaです。

カフカ

メッセージキューとは

サービス B を保護するために、サービス B のメモリにキューを追加することが簡単に考えられます。

メッセージキューはプロセスBにあります

簡単に言えば、これは実際にはリンク リストであり、リンク リスト内の各ノードはメッセージです。各ノードには、オフセットと呼ばれるシーケンス番号があり、メッセージの場所を記録します。サービス B は、独自の処理能力に基づいて、リンク リスト内のメッセージを消費します。可能な限り処理し、処理されたオフセットの値を継続的に更新します。

オフセットとは何ですか?

しかし、問題があります。時間内に処理されないメッセージはメモリに蓄積されます。サービス B が更新されて再起動されると、これらのメッセージは失われます。これは簡単に解決できます。キューを移動して別のプロセスにします。サービス B を再起動しても、キュー内のメッセージには影響しません。

メッセージキューは単一のプロセスである

このような単純なキュー プロセスは、実際にはメッセージ キューと呼ばれます。メッセージ キューにデータを送信するサービス A の役割はプロデューサーであり、メッセージを処理するサービス B の役割はコンシューマーです。

生産者と消費者

しかし、このメッセージ キューは実に単純すぎます。高性能、高スケーラビリティ、高可用性などの機能はありません。最適化する方法を見てみましょう。

高性能

サービス B のパフォーマンスが低いため、メッセージ キューにデータが蓄積され続けます。パフォーマンスを向上させるには、より多くのコンシューマーを追加して、消費速度を上げることができます。次に、プロデューサーを追加して、メッセージ キューのスループットを向上させることができます。

生産者と消費者を増やす

プロデューサーとコンシューマーの数が増えると、それらが同時に同じメッセージ キューを競合することがわかります。それを掴むことができない側は待つしかありません。これは完全に時間の無駄ではないでしょうか!解決策はありますか？持っている！まず、メッセージは分類されます。各カテゴリはトピックです。次に、トピックに追加された新しいキューの数に応じて、プロデューサーはトピックごとに異なるキューにデータを配信し、コンシューマーは必要に応じて異なるトピックをサブスクライブします。これにより、トピック キューの負荷が大幅に軽減されます。

複数のトピック

ただし、1 つのトピックにメッセージが多すぎる可能性があります。単一のキューを複数のセグメントに分割できます。各セグメントはパーティションであり、各コンシューマーはパーティションを担当します。これにより競合が大幅に減少し、メッセージ キューのパフォーマンスが向上します。

パーティション

高いスケーラビリティ

パーティションの数が増えると、すべてのパーティションが同じマシン上にある場合、単一のマシンの CPU とメモリの使用率が高くなりすぎて、システム全体のパフォーマンスに影響します。

したがって、より多くのマシンを申請し、複数のマシンにパーティションを展開することができます。これらの各マシンはブローカーを表します。ブローカーを追加することで、マシンの CPU 使用率の高さによって発生するパフォーマンスの問題を軽減できます。

ブローカ

高可用性

この時点では、実はまだ問題が残っています。パーティションの 1 つが配置されているブローカーがクラッシュすると、ブローカー内のすべてのパーティションのメッセージが失われます。高可用性についてどのように話せばいいのでしょうか?解決策はありますか？はい、あなたが好きな女の子でも、携帯電話で他の人とチャットすることは知っていますが、パーティションにバックアップを追加することは知らないのですか?パーティションにさらにコピー、つまりレプリカを追加し、それをリーダーとフォロワーに分割することができます。リーダーはプロデューサーとコンシューマーからの読み取りおよび書き込み要求を処理する責任があり、フォロワーはリーダーのメッセージを同期する責任のみを負います。

レプリカ

リーダーとフォロワーを異なるブローカーに分散します。これにより、リーダーが配置されているブローカーに障害が発生した場合でも、フォロワーが配置されているブローカーには影響が及ばず、フォロワーから新しいリーダー パーティションが選出されて引き継ぐことができます。これにより、メッセージ キューの高可用性が保証されます。

高可用性

持続性と有効期限戦略

今申し上げたのは、複数のブローカーが破綻する状況です。もっと広い視野で、すべてのブローカーが失敗すると仮定してみましょう。それはすべてのデータが失われることを意味するのではないですか?この問題を解決するには、データをメモリに保存するだけでなく、ディスクに保存する必要があります。この方法では、すべてのブローカーに障害が発生しても、データは失われません。サービスを再起動すると、ディスクからデータを読み取って作業を続行できます。

持続性

しかし、問題は再び発生します。ディスクは常に制限されています。データを書き込み続けると、遅かれ早かれ爆発してしまいます。したがって、データに保持ポリシー、いわゆる保持ポリシーを追加することもできます。たとえば、ディスクのデータが一定サイズを超えたり、メッセージが一定時間以上放置されたりした場合は、クリーンアップされます。

消費者団体

この時点で、メッセージ キューは完璧なようです。しかし、実際には問題があります。現在の消費パターンによれば、新しい消費者はそれぞれ、最新の消費オフセットに従ってのみ消費を継続できます。新しいコンシューマーが特定のオフセットから消費を開始するようにしたい場合はどうすればよいでしょうか?これは難しい要件のように思えますか?理解しやすいように例を挙げます。

サービス B に複数のインスタンスが存在する場合でも、本質的にはコンシューマー ビジネス パーティは 1 つだけであり、新しく追加されたインスタンスは通常、以前のオフセットから引き続き消費します。新しいビジネス パーティであるサービス C が登場し、メッセージ キュー内のデータを最初から使用したいとします。この時点では、サービス B の相殺後に消費を継続することはできません。

したがって、メッセージ キューにコンシューマ グループの概念を追加することもできます。サービス B と C はそれぞれ独立した消費者グループです。さまざまな消費者グループが互いに干渉することなく、独自の消費の進歩を維持します。

消費者グループは互いに独立している

動物園飼育員

コンポーネントが多すぎること、また各コンポーネントが独自のデータとステータスを持っていることがわかったと思います。そのため、これらのコンポーネントのステータス情報を統一的に管理するコンポーネントが必要であり、そこで ZooKeeper コンポーネントを導入します。ブローカーと定期的に通信して Kafka クラスター全体のステータスを取得し、一部のブローカーがクラッシュしたかどうか、一部のコンシューマー グループがどこで消費したかを判断します。

ZooKeeperに参加する

カフカとは何か

さて、この時点で、シンプルなメッセージ キューは、高性能、高スケーラビリティ、高可用性、永続的なメッセージ キューになりました。はい、よく話題になるのはメッセージ キュー Kafka です。パーティションやブローカーなど、これに関連するさまざまな概念はすべてここから来ています。

カフカとは何か

Kafkaの応用シナリオ

メッセージ キューは、アーキテクチャ内で最も一般的なミドルウェアの 1 つであり、使用シナリオが非常に多いため、万能薬とも言えます。たとえば、アップストリーム トラフィックが変動し、ピークを平滑化して谷を埋めて CPU/GPU の使用率を向上させたい場合に使用します。例えば、システムが大きすぎてメッセージフローが複雑で、コンポーネントを分解してシステムの結合を減らしたい場合などに利用します。例えば、フラッシュセール中はリクエストが急増し、ユーザーへの影響を最小限に抑えながらサービスを保護したい場合は、使用する必要があります。もちろん、絶対的なものは何もなく、実際の状況に応じて計画を決定する必要があります。結局のところ、建築とは妥協することです。

Kafka のアプリケーションシナリオ

要約する

• • Kafka はメッセージ キューです。プロデューサーはメッセージ キューにメッセージを配信する側であり、コンシューマーはメッセージを消費する側です。プロデューサー インスタンスとコンシューマー インスタンスの数を増やすと、システムのスループットが向上します。複数の消費者が消費者グループを形成することができ、異なる消費者グループは互いに干渉することなく独自の消費の進行を維持します。
• • Kafka はメッセージを複数のトピックに分割し、各トピックは複数のパーティションに分割され、各パーティションには独自のコピーがあり、異なるパーティションは異なるブローカーに分散されるため、パフォーマンスが向上し、システムの可用性とスケーラビリティが向上します。