ベテランプログラマーによる長年のまとめ: Kafka の高スループットの理由を解明

Kafka のスループットは一般的なメッセージキューよりも高く、最速であることはよく知られています。これはどうやって実現するのでしょうか?その理由を以下の側面から分析してみましょう。

プロデューサー（データを書き込む）

プロデューサーは、Kafka にデータを送信する責任があります。まずはこの部分を分析してみましょう。
Kafka は受信したすべてのメッセージをハードディスクに書き込み、データが失われることはありません。書き込み速度を最適化するために、Kafak はシーケンシャル書き込みと MMFile という2 つのテクノロジを使用します。

シーケンシャル書き込み

ハードディスクは機械的な構造であるため、読み取りと書き込みのたびにアドレス指定→書き込みのプロセスが発生しますが、その中でもアドレス指定は「機械的な動作」であり、最も時間がかかります。したがって、ハードドライブはランダム I/O を最も嫌い、シーケンシャル I/O を最も好みます。ハードディスクの読み取りと書き込みの速度を上げるために、Kafka はシーケンシャル I/O を使用します。

上の図は、Kafka がデータを書き込む方法を示しています。各パーティションは実際にはファイルです。メッセージを受信した後、Kafka はファイルの末尾 (破線部分) にデータを挿入します。
この方法には欠陥があり、データを削除する方法がないため、Kafka はデータを削除しません。すべてのデータが保持されます。各コンシューマーには、どのデータが読み取られたかを示すために、トピックごとにオフセットがあります。

上の図には、2 人の消費者がいます。 Consumer1 には、Partition0 と Partition1 に対応する 2 つのオフセットがあります (各トピックに 1 つのパーティションがあると仮定)。 Consumer2 には Partition2 に対応するオフセットが 1 つあります。このオフセットはクライアント SDK によって保存され、Kafka のブローカーはその存在を完全に無視します。通常、SDK はそれを Zookeeper に保存します。 (そのため、消費者に飼育係のアドレスを提供する必要があります)。
ハードディスクを削除しないと確実にいっぱいになってしまうので、Kakfa ではデータを削除するための 2 つの戦略を提供しています。 1 つは時間に基づき、もう 1 つはパーティション ファイル サイズに基づきます。具体的な設定については、設定ドキュメントを参照してください。

メモリマップファイル

ハードディスクにデータを順次書き込んでも、ハードディスクのアクセス速度がメモリに追いつきません。そのため、 Kafka のデータはリアルタイムでハードディスクに書き込まれるわけではありません。最新のオペレーティング システムのページング ストレージを最大限に活用してメモリを活用し、I/O 効率を向上させます。
メモリマップファイル（以下、mmap と略します）もメモリマップファイルに変換されます。 64 ビット オペレーティング システムでは、通常 20G のデータ ファイルを表すことができます。その動作原理は、オペレーティング システムのページを直接使用して、ファイルを物理メモリに直接マッピングすることです。マッピングが完了すると、物理メモリ上の操作がハードディスク (適切な場合はオペレーティング システム) に同期されます。

mmap を通じて、プロセスはハードディスクの読み書きと同じようにメモリ (もちろん仮想マシンのメモリ) を読み書きします。メモリのサイズは仮想メモリがカバーしてくれるので心配する必要はありません。
この方法を使用すると、I/O が大幅に改善され、ユーザー空間からカーネル空間へのコピーのオーバーヘッドが削減されます(ファイルの読み取りを呼び出すと、最初にデータがカーネル空間メモリに格納され、次にユーザー空間メモリにコピーされます)。また、非常に明らかな欠陥として、信頼性の低さがあります。 mmap に書き込まれたデータは、実際にはハードディスクに書き込まれません。プログラムが実際に flush を呼び出すまで、オペレーティング システムはデータをハード ディスクに書き込みません。 Kafka は、アクティブにフラッシュするかどうかを制御するためのパラメーター producer.type を提供します。 Kafka が mmap に書き込んだ直後にフラッシュして Producer に戻る場合、それは同期 (sync) と呼ばれます。 Kafka が flush を呼び出さずに mmap に書き込んだ直後に Producer に戻る場合、それは非同期 (async) と呼ばれます。
Mmap は実際にはメモリ マッピングを実装するために使用される Linux の機能です。 Java NIO のおかげで、メモリ マッピングを実装するために使用できる MappedByteBuffer クラスが提供されます (Java のおかげで非常に高速になり、Scala とはまったく関係ありません)。

コンシューマー（データ読み取り）

Kafka はディスク ファイルを使用しており、高速化を望んでいますか?これはカフカを見た後の最初の疑問でした。 ZeroMQ にはサーバー ノードがなく、ハード ディスクも使用しません。論理的には、Kafka よりも高速になるはずです。しかし、実際のテストでは、その速度は依然として Kafka に負けています。 「ハードディスクを使う方がメモリを使うよりも速い」というのは全く常識に反します。これが起こった場合、それは不正行為であることを意味します。
そうです、カフカは「ごまかし」をします。シーケンシャル書き込みと mmap はどちらも、実際には不正行為の準備です。

Web サーバーの静的ファイルの速度を向上させるにはどうすればよいでしょうか?

静的ファイルを配信する Web サーバーを最適化する方法について、よく考えてみましょう。答えはゼロコピーです。従来のモードでは、ハードディスクからファイルを次のように読み取ります。

まずカーネル空間にコピーし（読み取りはシステムコールなので DMA に配置し、カーネル空間を使用します）、次にユーザー空間にコピーします（1,2）。それをユーザー空間からカーネル空間に再度コピーし（使用するソケットはシステムコールなので、独自のカーネル空間もあります）、最後にネットワークカードに送信します（3、4）。

カーネル空間 (DMA) からカーネル空間 (ソケット) へゼロコピーを直接実行し、ネットワーク カードに送信します。
この技術は非常に一般的です。 C10K問題でも詳しく紹介されています。 Nginx もこの技術を使用しています。簡単に検索すればたくさんの情報が見つかります。

Java の NIO は FileChannle を提供します。その transferTo メソッドと transferFrom メソッドは Zero Copy です。

Kafka はどのように不正行為をするのでしょうか?

それについて考えたことはありますか？ Kafka はすべてのメッセージを 1 つずつファイルに保存し、コンシューマーがデータを必要とするときに、Kafka は「ファイル」を直接コンシューマーに送信します。これが秘密です。たとえば、100,000 件のメッセージが 10 MB のデータに結合されます。その後、Kafka はファイルを送信するのと同様の方法でそれを直接送信します。消費者と生産者の間のネットワークが非常に良好であれば（ネットワークが少し正常であれば、10MB はまったく問題ではありません...自宅のインターネット帯域幅は 100Mbps です）、 10MB は 1 秒しかかからない場合があります。答えは 10W TPS です。Kafka は 1 秒あたり 10W のメッセージを処理します。
ファイル全体を送信するのは不可能ですか? と疑問に思うかもしれません。不要なメッセージは含まれていますか?はい、 「高度な詐欺師」であるカフカは、当然ながら上品な方法で詐欺をしなければなりません。ゼロコピーはsendfile関数（Linuxを例に挙げる）に対応し、

出力としてのout_fd（通常はソケットハンドル）

in_fdは入力ファイルハンドルです

off_t は in_fd のオフセット（読み取りを開始する場所）を表します。

size_tは読み取る数を示します

それは正しい。 Kafka はファイルの読み取りおよび書き込み方法として mmap を使用します。これはファイルハンドルなので、sendfile に渡すだけです。オフセットも簡単に解決できます。ユーザーはオフセットを自分で保持し、リクエストごとにオフセットを送信します。 (覚えていますか? Zookeeper に入れてください);データ量が多いほど解決しやすくなり、消費者がもっと早く欲しい場合は、すべてを消費者に渡すだけで済みます。これをやると、消費者は大抵圧死することになる。したがって、Kafka は 2 つのメソッドを提供します。Push は、すべてをあなたに投げるので、あなたが死んでも私には関係ありません。引っ張って、いいですよ、何本必要か言ってください、その分だけ差し上げます。

要約する

Kafka の高速性の秘密は、すべてのメッセージを 1 つのファイルに変換することです。 mmap を使用することで I/O 速度が向上します。データを書き込む際、最後に追加されるため速度が最適になります。データを読み込む際、sendfile で強制的に直接出力します。 Alibaba の RocketMQ もこのモデルを使用していますが、Java で記述されています。

MQ の速度を単にテストするだけでは意味がありません。 Kafka の「暴力的」、「無法」、「恥知らず」なアプローチは MQ の本質を奪い、MQ を暴力的な「データ送信機」のようなものに変えてしまいました。したがって、MQ の評価は速度のみに基づいて行われます。世界中にカフカを超える人はいない。設計する際には、インターネット上の噂を信じてはいけません。「Kafka は最速で、誰もが使っているので、MQ には Kafka を使うのが正解だ」このような考え方では、「敗者」のことをまったく気にしないかもしれません。実際、これらの「敗者」は、あなたのビジネスにより適した MQ である可能性があります。