Kafka がバッファプールのメカニズムを設計するのはなぜですか?最初は戸惑いましたが、理解した後はひざまずきました。

この記事では、ハードコアな技術的知識についても説明します。 Kafka カーネル ソース コードのいくつかの設計アイデアを通じて、Kafka アーキテクチャを設計した技術専門家が JVM GC 問題をどのように最適化したかを見てみましょう。

1. Kafka のクライアントバッファリングメカニズム

まず、皆さんに一つ明確にしておかなければならないことがあります。それは、クライアントが Kafka サーバーにメッセージを送信するときに、メモリ バッファー メカニズムがなければならないということです。

つまり、メッセージは最初にメモリ バッファーに書き込まれ、その後、複数のメッセージがバッチを形成するまで、バッチは 1 回の通信でネットワーク経由で送信されます。

全体のプロセスを下の図に示します。

2. メモリバッファリングによる頻繁なGC問題

このメモリ バッファ メカニズムの本来の目的は、複数のメッセージを 1 つのバッチにグループ化することです。 1 つのネットワーク リクエストは 1 つのバッチまたは複数のバッチです。

この方法では、各ネットワーク要求で大量のデータを送信できるため、メッセージごとに 1 つのネットワーク要求が回避されます。これにより、スループット、つまり単位時間あたりに送信されるデータ量が向上します。

しかし、ここで問題が発生します。考えてみて下さい。バッチ内のデータは取り出され、基盤となるネットワーク パケットにカプセル化され、ネットワーク経由で Kafka サーバーに送信されます。

それでどうするの？このバッチ内のすべてのデータが送信されました。バッチ内のデータはどのように処理すればよいでしょうか?

これらのバッチ内のデータは、クライアントの JVM のメモリ内にまだ残っていることを知っておく必要があります。この時点で、コード実装レベルから、変数がこれらのバッチに対応するデータを参照しないようにし、JVM がこれらのメモリ ガベージを自動的にリサイクルするようにトリガーする必要があります。

このようにして、JVM は継続的にガベージをリサイクルし、正常に送信されたバッチをクリーンアップして、新しいデータが使用できるように新しいメモリ領域を継続的に解放することができます。

このアイデアは良いですが、実際にオンラインで実行すると間違いなく問題が発生します。最大の問題は JVM GC の問題です。

JVM GC がメモリ ガベージをリサイクルするときに、「Stop the World」プロセスが実行されることは誰もが知っています。つまり、ガベージ コレクション スレッドの実行中に、他の作業スレッドが短時間一時停止され、メモリ ガベージを静かにリサイクルできるようになります。

これもわかりやすいですね。結局のところ、メモリ ガベージをリサイクルしている間もワーカー スレッドがメモリにデータを書き込み、さらにメモリ ガベージを作成している場合、JVM にガベージをリサイクルさせるにはどうすればよいのでしょうか。

まるで、道にゴミがたくさんあるので、それを掃除したいと思っているようなものです。一番いい方法は何ですか？全員が道を空けるために道を空け、その後、清掃員がゴミを片付けます。

しかし、清掃員がゴミを清掃していて、その隣にメロンの種を食べたり殻を捨てたり、スイカを食べたり皮を捨てたりしながら、絶えずゴミを出している人々が立っていたら、清掃員はどう感じると思いますか?もちろん私は非常に憤慨しています。このままだと地面のゴミはいつまでも片付かないよ！

上記の言語による説明を通して、より明確になるように画像を見てみましょう。

現在、JVM GC は CMS ガベージ コレクターから G1 ガベージ コレクターへとますます進化しています。主な目標の 1 つは、ガベージ コレクションによって他の作業スレッドが一時停止する時間を継続的に短縮することです。

したがって、ガベージ コレクターが新しくなるほど、作業スレッドが一時停止される時間は短くなりますが、どれだけ短くても、スレッドは依然として存在します。

したがって、独自の設計で JVM の頻繁な GC を可能な限り回避する方法は非常に困難な作業です。

3. Kafka 設計者によって実装されたバッファプールのメカニズム

Kafka クライアントには、この問題を解決するための非常に優れたメカニズム、つまりバッファ プール メカニズムが実装されています。

簡単に言えば、各バッチの基盤となるレイヤーは、書き込まれたメッセージを格納するために特別に使用されたメモリ空間の一部に対応します。

その後、バッチが Kafka サーバーに送信されると、このバッチ内のデータは不要になり、このバッチのメモリ領域は使用されなくなります。

このとき、バッチの下部にあるメモリ領域は、ガベージ コレクションのために JVM に引き渡されるのではなく、バッファ プールに配置される必要があります。

このバッファプールには大量のメモリスペースが含まれています。次回、新しいバッチを実行する場合、このバッファ プールからメモリ領域の一部を取得することはできないでしょうか?

では、バッチが送信された後、メモリ領域を所有者に返す方がよいのではないでしょうか?そして、このサイクルが繰り返されます。

同様に、上記のテキストの説明を聞いた後に、別の画像を示します。この写真を見れば誰もが理解できると思います。

このバッファ プール メカニズムを使用すると、大量のメモリに関連する GC の問題が頻繁に発生しなくなります。

なぜ？ 32MB などの固定量のメモリを占有できるためです。次に、32MB を N 個の複数のメモリ ブロックに分割します。たとえば、メモリ ブロックは 16 KB です。この方法では、バッファ プールに多数のメモリ ブロックが存在することになります。

次に、新しいバッチを作成し、バッファー プールから 16 KB のメモリ ブロックを取得する必要があります。その後、このバッチはメッセージの書き込みを続行しますが、バッチの基盤となるメモリ ブロックは 16 KB であるため、最大 16 KB が書き込まれます。

その後、バッチが Kafka サーバーに送信されると、バッチの基礎となるメモリ ブロックをバッファー プールに直接返すことができます。

次に誰かがバッチを構築するときには、バッファー プール内のメモリ ブロックを再び使用できます。このようにして、限られたメモリを繰り返し利用して再利用することができます。バッチを使用した後にメモリ ブロックをバッファー プールに戻すと、ガベージ コレクションは実行されなくなるためです。

頻繁なガベージ コレクションが行われない場合、作業スレッドの頻繁な一時停止は自然に回避できます。 JVM GC の問題は大幅に最適化されるでしょうか?

はい、この設計コンセプトにより、Kafka クライアントのパフォーマンスとスループットが非常に高くなり、優れたメカニズムが多数組み込まれています。

そこで誰かが、バッファ プール内のすべてのメモリ リソースがいっぱいになってしまい、一時的にバッファ プールにメモリ ブロックがない場合はどうすればいいかと尋ねました。

とても簡単です。書き込み操作がブロックされ、メッセージの書き込みを続行できなくなります。ブロックされ、メモリ ブロックが解放されるまで待機させられ、その後、再度メッセージを書き込むことができます。

4. まとめ

この記事では、Kafka のメモリ バッファ メカニズムの設計思想から始め、JVM GC の問題の原因と悪影響を分析します。

次に、Kafka の優れたバッファ プール メカニズムの設計アイデアと、それがこの問題をどのように解決するかについて話し、設計中に Kafka の作者によって実証された多くの優れた技術設計アイデアと機能を分析しました。

皆さんがここで学んだエッセンスを吸収し、これらの優れたアイデアを今後の面接や仕事に活かしていただければ幸いです。