なぜカフカはとても速いスピード？
カフカのメッセージが格納されているか、ディスクにキャッシュされ、一般的に多くの時間がかかりますが、実際には、カフカの特徴の一つは、高スループットだろう対処するため、ディスク上の読み取りおよび書き込みデータはパフォーマンスが低下すると考えられています。
でも普通のサーバー、カフカが簡単メッセージングミドルウェアのほとんどよりも、第二のレベルごとの書き込み要求の数百万人のためにサポートすることができ、この機能は、カフカが広く、そのような場面として、大量のデータを処理し、ログに使用することができます。
ベンチマークについてカフカは、Apacheのカフカのベンチマークを参照することができます：書き込み秒あたり2万人（3低コストのマシン上で）
書き込みと読み取りの両方の分析から以下のデータは、なぜカフカ非常に高速。
書き込みデータ
カフカは、メッセージが、それはデータを失うことはありません、ハードディスクに書き込まれている受信します。書き込み速度を最適化するにはカフカは二つの技術、使用するシーケンシャル書き込みとMMFileを。
シーケンシャル書き込み
ディスクの読み取りと書き込み速度は、あなたがそれを使用する方法に依存し、それは、シーケンシャルリードとライトまたはランダム読み取りおよび書き込みです。シーケンシャルリード、ライト、シーケンシャルリードと書き込み速度とメモリディスク変わらずの場合。
ハードディスクが機械的な構造であるため、それぞれの読み取りと書き込みアドレスです - アドレスが「機械的作用」であることを特徴とする請求>書き込みは、それはほとんどの時間を消費します。ハードディスクは、ほとんどのシーケンシャルI / OのようなランダムI / Oを、嫌いだから ハードディスクの読み取りおよび書き込み速度を向上させるためには、カフカは、シーケンシャルI / Oを使用することです
Linuxと最適化ディスクの読み取りと書き込みのために先に読み取りと書き込みの背後に、ディスクキャッシュを含め、より多くなります。メモリ内のこれらの操作を行うための時間、偉大なメモリのオーバーヘッドJavaオブジェクトは、他のデータの増加とヒープメモリの場合は、GCのJAVAは、非常に長い時間となり、ディスク操作は、次のような利点があります使用します。
- シーケンシャルリードとライト・ディスクは、ランダムアクセスメモリを超えます
- 低効率のJVM GC、大きなメモリフットプリント。使用ディスクは、この問題を回避します
- コールドスタートシステムの後、ディスクキャッシュはまだ入手可能です
文書メッセージデータを受信した後、実際に各パーティションにカフカ書き込みデータがカフカファイル（仮想フレーム部分）の端部を挿入する方法を次の図に示します：
このメソッドは、欠点を持っている - デリートデータに方法がない、カフカはなりません、削除データ、それはすべてのデータは保持されます、各トピックについて、各コンシューマ（消費者）がオフセットしているが示すのに使用されます最初のいくつかのデータを読み込みます。
2つのコンシューマ：
- Consumer1 partition0で、パーティション1（各トピックパーティションを想定）に対応するオフセット2があります。
- Consumer2は、パーティション2に対応するオフセット。
通常の状況下SDKはそれを飼育係の内部に保存されます、アドレスのZooKeeper消費者に提供する必要があるので、これは、クライアントSDKを維持する責任があり、カフカのブローカーは、完全にこの事を無視オフセット。
あなたが削除しなかった場合Kakfaは、データを削除するには2つの戦略を提供しますので、ハードディスクは確かに、いっぱいになります。
- 一つは、時間に基づいています。
- 第二は、パーティション、ファイルサイズに基づいています。
具体的な構成は、設定ファイルに記載されています。
メモリマップトファイル
順序は、ハードディスクのアクセス速度に書き込まれている場合でも、まだキャッチメモリには不可能です。だから、カフカがリアルタイムデータがディスクに書き込まれていない、それはメモリI / O効率の利用を高めるために近代的なオペレーティングシステムのページングメモリをフルに活用します。
ファイル（後のmmapと呼ばれる）マップされたメモリは、メモリマップファイルに変換され、64ビットのオペレーティングシステムでは、一般的に、データファイル20Gを表すことができ、その動作原理は、オペレーティングシステムの直接使用されているページは、物理メモリへのファイルの直接マッピングを実現。
あなたは、物理メモリのマッピング操作を完了した後、ハードドライブ（オペレーティングシステムの適切な）に同期されます。
MMAPすることで、（もちろん、仮想マシンのメモリ）読み書きメモリなどのハードとして読み書きのプロセスは、私たちはすべての詳細を明らかにするための仮想メモリのメモリサイズを心配する必要はありません。
あなたがコピーにカーネル空間にユーザ空間のオーバーヘッドを排除し、I / Oの多くは、アップグレードを得ることができるこの方法は、（読み取りデータは、カーネルメモリ空間に最初のファイルを呼び出し、その後、ユーザメモリ空間にコピーされますインチ）
しかし、明らかな欠陥がある - プログラムが自動的にのみ呼び出してデータをフラッシュするときにmmapで記述された信頼性の低いデータは本当にハードディスクに書き込まれていなかった、オペレーティングシステムがハード本当の書き込み。
カフカは、カフカが同期（シンク）と呼ばれるプロデューサーを返す直前にフラッシュmmapの後に書かれた場合に制御するパラメータは、アクティブ--producer.typeフラッシュではありません提供し、すぐにmmapプロデューサー非同期呼び出しを書き込んだ後リターンは、（フラッシュを呼び出すことはありません。非同期）。
読み取りデータ
ディスクを読み込むときカフカは何の最適化をしましたか？
sendfileをゼロコピーを実現基づき、
ファイルを送信する必要がある伝統的なモードでは、特定のプロセスの詳細は、以下のようにしています。
- 読み込み関数を呼び出し、ファイルデータは、カーネルバッファをコピーすることです
- ユーザバッファに関数が戻る、カーネルバッファからファイルコピーデータを読み込みます
- ユーザーバッファからカーネルへの書き込み関数呼び出し、ファイルコピーデータがソケットに関連するバッファ。
- 関連するプロトコルエンジンへのソケットバッファからデータをコピーします。
詳しくは、ネットワークファイル転送のための読み取り/書き込みモードの伝統的な方法で、我々は、このプロセスでは、データファイルは、実際には4つのアクションを通じてコピーであることを確認できます。
ハードドライブ - >カーネルbuf->ユーザーbuf->ソケットバッファ関連 - >プロトコルエンジン
sendfileシステムコールは、ファイル転送方式の性能を向上させる、上記繰り返しコピーを減少させる方法を提供します。
バージョン2.1のカーネル、sendfileのシステムコールは、ネットワークおよび2つのローカルファイル間のデータ伝送を簡素化するために導入されます。SENDFILEは、コンテキストスイッチングを減らすだけでなく、データの複製を低減紹介しました。
sendfile(socket, file, len);
复制代码次のように実行するプロセスは、次のとおりです。
- sendfileシステムコール、ファイルデータは、カーネルバッファをコピーすることです
- そして、カーネルバッファのコピーからカーネルのソケットバッファに関連します
- 最後に、ソケット関連のプロトコルエンジンにコピーをバッファリング
伝統的な読み取り/書き込みモードと比較すると、カーネルのsendfileカーネルバッファの2.1バージョンの導入は、ユーザバッファに縮小されました、その後、関連するバッファバッファソケットにユーザーからファイルをコピーし、そしてカーネルのバージョン2.4の後、ファイルディスクリプタ結果sendfileをもう一度コピー操作を減らし、より簡単な方法を達成するために、変更されました。
その上のApache、nginxの、lighttpdのWebサーバとの中で、sendfileの関連構成を有している、使用のsendfileは大幅にファイル転送のパフォーマンスを向上させることができます。
カフカのすべてのメッセージは、ファイルに格納され、消費者のニーズが読み書きモードのmmapを持つファイルとして、消費者に直接カフカファイルをデータを送信する際に、直接のsendfileを渡します。
バッチ圧縮
多くの場合、ボトルネックはCPUやディスクではなく、ネットワークIO、データセンター間でメッセージを送信するために特に必要性は、データ線をWAN。データ圧縮は、CPUリソースの少量を消費しますが、カフカのために、ネットワークIOを考慮すべきです。
- 各メッセージが圧縮されているが、カフカバッチ圧縮を使用するように、圧縮率が比較的低い場合、圧縮は、単一のメッセージの圧縮ではなく、一緒に複数のメッセージを今後
- カフカは、メッセージの帰納的集合を可能にする、メッセージの容量がログによって圧縮された形で送信することができ、圧縮形式で保持することができ、消費者は、溶液になるまで圧縮されます
- カフカは、Gzip圧縮プロトコルとスナッピーを含む複数の圧縮プロトコルをサポートしています
概要
そのバッチファイルにすべてのメッセージ、および合理的なバルク圧縮のmmap I / O速度を改善することにより、ネットワークIOの損失を低減することカフカ速度秘密、書き込みデータが原因単一Partionに最後に追加されたときしたがって、最適な速度;直接出力のsendfile暴力を使用してデータを読み出します。
