Kafkaは、もともとLinkedinによって開発されました。これは、分散、分割、マルチコピー、マルチサブスクライバーです。これは、zookeeperによって調整される分散ロギングシステムに基づいています（MQシステムとしても使用できます）。これは、一般にWeb / nginxのログとアクセスに使用されますログ、メッセージングサービスなど、Linkedinは2010年にApache Foundationに貢献し、トップレベルのオープンソースプロジェクトになりました。
主なアプリケーションシナリオは、ログ収集システムとメッセージシステムです。
Kafkaの主な設計目標は次のとおりです。
- メッセージの永続化機能はO（1）の時間の複雑さで提供され、テラバイトレベルを超えるデータに対しても一定時間のアクセスパフォーマンスを保証できます。
- 高スループット。非常に安価な商用マシンであっても、1台のマシンで毎秒100Kメッセージの送信を実現できます。
- Kafkaサーバーと分散消費の間のメッセージ分割をサポートし、各パーティション内でのメッセージの順次送信を保証します。
- また、オフラインデータ処理とリアルタイムデータ処理もサポートしています。
- スケールアウト：オンライン水平拡張をサポート
1.
Kafkaの特徴高スループット：Kafkaは、毎秒約250,000メッセージ（50 MB）を生成し、毎秒550,000メッセージ（110 MB）を
処理できます永続的なデータストレージ：永続的な操作を実行できます。ディスクへの永続的なメッセージ。ETLなどの大量消費やリアルタイムアプリケーションに使用できます。データをハードディスクに保存して複製することにより、データの損失を防ぎます。
分散システムは簡単に拡張できます。複数のプロデューサー、ブローカー、コンシューマーが存在し、それらすべてが分散されます。機械はダウンタイムなしで拡張できます。
クライアント状態のメンテナンス：処理中のメッセージの状態は、サーバー側ではなくコンシューマ側で維持されます。それは失敗したときに自動的にバランスをとることができます。
2.トピック、プロデューサー、コンシューマー
1.
トピックは、メッセージのグループの要約です。Kafkaはトピックごとにログを分割します。
各パーティションは、パーティションに連続的に追加される一連の不変のメッセージで構成されます。
パーティション内の各メッセージには、オフセットと呼ばれる連続したシーケンス番号があり、パーティション内のメッセージを一意に識別するために使用されます。
構成可能な期間内に、Kafkaクラスターは、消費されたかどうかに関係なく、公開されたすべてのメッセージを保持します。たとえば、メッセージ保持ポリシーが2日に設定されている場合、メッセージは投稿されてから2日以内に消費されます。その後、スペースを解放するために破棄されます。
Kafkaのパフォーマンスは一定であり、データの量とは無関係であるため、大量のデータを保持しても問題ありません。
各パーティションは、Kafkaクラスター内のいくつかのサービスにコピーを持っているため、コピーを保持するこれらのサービスは、データと要求を共同で処理でき、コピーの数を構成できます。このコピーにより、Kafkaはフォールトトレラントになります。
各パーティションには、「リーダー」として1つのサーバー、「フォロワー」としてゼロまたは複数のサーバーがあり、リーダーはメッセージの読み取りと書き込みの処理を担当し、フォロワーはリーダーをコピーします。リーダーがダウンしている場合、フォロワーの1つは自動的にリーダー。クラスター内の各サービスは、同時に2つの役割を果たします。それは、それが保持するパーティションの一部のリーダーとして、および他のパーティションのフォロワーとして、クラスターがより良いロードバランスを持つようにします。
ログを分割すると、次の目的を達成できます。まず、これにより、各ログの数が多くなりすぎず、1つのサービスに保存できます。さらに、各パーティションを個別に発行および使用できるため、同時操作トピックの可能性が提供されます。
パーティショニングは、ロードバランシングが失敗したときに分散データストレージを回復するための基本単位です。
2.
プロデューサープロデューサーは、指定したトピックにメッセージをパブリッシュし、どのパーティションにパブリッシュするかを決定します。通常、パーティションは負荷分散メカニズムによってランダムに選択されますが、特定のパーティション機能によって選択することもできます。2つ目はより使用されます。
3.コンシューマ
実際、各コンシューマが維持する必要がある唯一のデータは、ログ内のメッセージの位置であるオフセットです。このオフセットはコンシューマによって維持されます。一般に、コンシューマがメッセージを継続的に読み取ると、このオフセットの値は増加し続けますただし、実際には、コンシューマはメッセージを任意の順序で読み取ることができます。たとえば、オフセットを古い値に設定して、前のメッセージを再度読み取ることができます。
上記の機能の組み合わせにより、Kafkaコンシューマーは非常に軽量になります。クラスターや他のコンシューマーに影響を与えることなくメッセージを読み取ることができます。コマンドラインを使用すると、メッセージを消費している他のコンシューマーに影響を与えることなくメッセージを「テール」できます。
通常、メッセージを消費するモードには、キューイングモードとパブリッシュ/サブスクライブモードの2つがあります。
（1）キューモード
キューモード、複数のコンシューマーが同時にサーバーからメッセージを読み取ることができ、各メッセージはいずれかのコンシューマーによってのみ読み取られます;
（2）パブリッシュサブスクライブモード
パブリッシュサブスクライブモードメッセージはすべてのコンシューマーにブロードキャストされますで。
（3）コンシューマはコンシューマグループに参加できます。グループ内のコンシューマは、トピック内のメッセージをめぐって競争します。トピック内のメッセージは、グループのメンバーに配信され、同じメッセージのみが送信されます。消費者。同じグループの消費者は、異なるプログラムまたは異なるマシンにいる可能性があります。同じトピックのメッセージを消費する複数のコンシューマーグループがある場合、グループとグループは共有データの状態にあり、各グループはこのトピックのすべてのメッセージを取得できます。
すべてのコンシューマがグループに属している場合、これは従来のキューモードになり、コンシューマ間でロードバランシングが実現されます。
すべてのコンシューマーが異なるグループに属していない場合、これはパブリッシュ/サブスクライブモデルになり、すべてのメッセージがすべてのコンシューマーに配信されます。
より一般的には、各トピックには消費用のコンシューマグループがいくつかあります。各グループは論理的な「サブスクライバ」です。フォールトトレランスと安定性を高めるために、各グループは複数のコンシューマで構成されています。グループ内で競争して、負荷分散を実現します。両群間のロードバランシングを実現するグループ内の競争は、実際に公開されており、互いに独立して、共有-購読モデルが、加入者ではなく、単一の消費者団体である
従来のメッセージングシステムに比べて、3
従来のキューは、順序付けられたメッセージをサーバーに格納します。複数のコンシューマーがこのサーバーからのメッセージを同時に消費する場合、サーバーはメッセージが格納された順序でメッセージをコンシューマーに配信します。サーバーは順番にメッセージをパブリッシュしますが、メッセージは非同期にコンシューマーに配信されるため、メッセージが到着したときに元の順序が失われている可能性があります。つまり、同時使用により順序が乱れる可能性があります。障害を回避するために、このようなメッセージシステムは通常「専用コンシューマ」の概念を使用します。実際には、1つのコンシューマだけがメッセージを消費できます。これは当然、同時実行性が失われることを意味します。
複数のコンシューマグループが同時に存在する場合、分割の概念を通じて、Kafkaはより良い順序付けと負荷分散を提供できます。各パーティションは1つのコンシューマグループにのみ配布されるため、パーティションはこのグループの1つのコンシューマによってのみ消費され、このパーティションのメッセージは順番に消費できます。複数のパーティションがあるため、複数のコンシューマグループ間で負荷を分散することが依然として可能です。コンシューマグループの数はパーティションの数を超えることはできません。つまり、可能な限り多くのパーティションで同時使用が可能です。
Kafkaは、パーティション内のメッセージの秩序性のみを保証できます。異なるパーティション間では不可能です。これは、ほとんどのアプリケーションのニーズをすでに満たしています。トピック内のすべてのメッセージの順序が必要な場合は、このトピックにパーティションを1つだけ含めることができます。もちろん、1つのコンシューマーグループだけがそれを使用します。
4番目に、ビッグデータ環境のメッセージキューがカフカを選択することが多いのはなぜですか？
分散ファイルシステム、より高い信頼性、性能のスケーラビリティ提供する
大容量データ記憶能力を提供ディスク・ストレージ・データと、トピックによって、パーティション分散ファイルシステム、永続ストレージ、
データを格納するディスクを使用して、連続的に読み取ります保証されたパフォーマンス、パフォーマンスはディスクのパフォーマンスに関連し、データの量とは関係ありません
5. Kafkaの書き込み操作はなぜ速いのですか？
主にディスクの使用方法の違いによるものです。Kafkaはすべてのデータをディスクに永続化しますが、基本的に、すべての書き込み操作は実際にはオペレーティングシステムのページキャッシュにデータを書き込むだけであり、ページキャッシュのデータをディスクに書き戻すタイミングは、オペレーティングシステムが決定します。この設計には大きな利点があります
。1.オペレーティングシステムのページキャッシュがメモリに割り当てられるため、メッセージの書き込み速度が非常に高速です。
2. Kafkaは、基礎となるファイルシステムを直接処理する必要はありません。厄介な1/0操作はすべてオペレーティングシステムによって処理されます。
3. Kafka書き込み操作では、ランダムディスク書き込み操作を回避するために、追加書き込み（append）メソッドが採用されています。
Kafkaは、高スループットと低遅延の設計目標を達成するために、次の4つのポイントに依存しています。
1.オペレーティングシステムのページキャッシュが大量に使用され、メモリの動作速度が速く、ヒット率が高い。
2. Kafkaは物理的な1/0操作に直接参加しませんが、最適なオペレーティングシステムに引き渡されます。
3.追加書き込みを採用し、低速ディスクのランダム読み取り/書き込み操作を破棄します。
4. sendfileに代表されるゼロコピー技術を使用して、ネットワーク間のデータ転送の効率を高めます。
第6に、メッセージの永続性
Kafkはメッセージを永続化することであり、メッセージはディスクに永続化する必要があります。これの利点は次のとおりです。
メッセージ送信とメッセージ消費の分離：基本的に、Kafkaのコア機能は、プロデューサー/コンシューマーモデルの完全なソリューションを提供することです。メッセージを永続化することにより、プロデューサー側はコンシューマー側と直接結合する必要がなくなり、メッセージを生成してKafkaサーバーに送信して保存するだけでよいため、全体的なスループットが向上します。
柔軟なメッセージ処理の実現：Kafkaのダウンストリームサブシステム（Kafkaメッセージを受信するシステム）には、すでに処理済みのメッセージが将来のある時点で再処理される、いわゆるメッセージ再生（メッセージの再生）。メッセージの永続化は、この要求を簡単に達成できます。
さらに、カフカの持続性設計も斬新です。通常のシステムでは、永続性を実装するときにメモリを可能な限り使用する可能性があります。メモリリソースが使い果たされると、データは再び「スワイプ」されます。Kafkaはその逆を行い、すべてのデータがすぐにファイルに書き込まれます。システムの永続ログで、Kafkaサーバーは結果をクライアントに返し、メッセージが正常に書き込まれたことを通知します。これにより、データがリアルタイムで保存されるだけでなく、Kafkaプログラムのメモリ消費も削減されるため、保存されたメモリはページキャッシュ用に予約され、全体的なパフォーマンスがさらに向上します。
7、負荷分散とフェイルオーバー
完全に機能する分散システムとして、Kafkaが最も基本的なメッセージエンジン機能のみを提供する場合、それを際立たせるのに十分ではありません。完全なメッセージエンジンソリューションは、ロードバランシング（Cloadバランシング）およびフェイルオーバー（fai l-over）機能を提供する必要があります。
デフォルトでは、Kafkaの各サーバーは、Kafkaの顧客にサービスを提供する機会が等しく、「特定のサーバーが枯渇する」状況を回避するために、クラスター内のすべてのマシンに負荷を分散できます。Kafkaは、デフォルトで非常にインテリジェントなリーダー選出アルゴリズムを提供します。これにより、クラスター内のすべてのマシンに均等な機会で各パーティションのリーダーを分散できるため、全体としてロードバランシングを実現できます。
負荷分散に加えて、完全な分散システムはフェイルオーバー（いわゆるフェイルオーバー）もサポートする必要があります。これは、サーバーが予期せず中断された場合、クラスター全体が障害を迅速に検出でき（fai lur）、サーバー上のアプリケーションまたはサービスが即座に実行されることを意味します他のサーバーへの自動転送フェイルオーバーは通常、「ハートビート」または「セッション」メカニズムによって実装されます。つまり、メインサーバーとバックアップサーバー間のハートビートを維持できないか、メインサーバーのサービスセンターへの登録のセッションタイムアウトが期限切れになる限り、次に、メインサーバーが正常に動作しなくなったと見なされ、クラスターが自動的にバックアップサーバーを起動して、メインサーバーの作業を置き換えます。
Kafkaサーバーがフェイルオーバーをサポートする方法は、セッションメカニズムを使用することです。各Kafkaサーバーは、起動後、セッションの形でZooKeeperサーバーに登録されます。サーバーの操作に問題が発生すると、ZooKeeperとのセッションを維持できなくなり、タイムアウトが発生します。この時点で、Kafkaクラスター
は別のサーバーを選び、このサーバーを完全に置き換えてサービスを提供し続けます。
一般的に使用されるメッセージキューの比較
RabbitMQ
RabbitMQは、Erlangで記述されたオープンソースのメッセージキューです。AMQP、XMPP、SMTP、STOMPなどの多くのプロトコルをサポートしています。そのため、非常に重く、エンタープライズレベルの開発に適しています。同時に、ブローカーフレームワークが実装されます。つまり、メッセージはクライアントに送信される前に中央キューに入れられます。ルーティング、ロードバランシング、またはデータの永続化を適切にサポートしています。
Redis
RedisはKey-Valueペアに基づくNoSQLデータベースであり、開発とメンテナンスは非常に活発です。Key-Valueデータベースストレージシステムですが、それ自体がMQ関数をサポートしているため、軽量キューサービスとして使用できます。RabbitMQおよびRedisのエンキューおよびデキュー操作では、それぞれ100万回実行され、実行時間は100,000回ごとに記録されます。テストデータは、128バイト、512バイト、1K、10Kの4つの異なるサイズのデータに分割されます。実験によると、データが比較的小さい場合、チームに入るときのRedisのパフォーマンスはRabbitMQより高く、データサイズが10Kを超えると、Redisは耐えられないほど遅くなります。チームを離れるとき、Redisはデータサイズに関係なく非常に優れたパフォーマンスを示します、そしてRabbitMQのデキューのパフォーマンスはRedisよりもはるかに低いです。
ZeroMQ
ZeroMQは、特に高スループットの需要シナリオにおいて、最速のメッセージキューシステムとして知られています。ZeroMQは、RabbitMQが得意ではない高度で複雑なキューを実装できますが、開発者は複数の技術フレームワークを組み合わせる必要があります。技術的な複雑さは、このMQアプリケーションの成功への挑戦です。ZeroMQには非ミドルウェアの独自のモードがあり、アプリケーションがこのサーバーの役割を果たすため、メッセージサーバーやミドルウェアをインストールして実行する必要はありません。NuGetを使用してインストールできるZeroMQライブラリを引用するだけで、アプリケーション間でメッセージをスムーズに送信できます。ただし、ZeroMQは非永続的なキューのみを提供するため、キューが停止するとデータが失われます。その中でも、0.9.0より前のTwitterのStormバージョンは、デフォルトでデータストリームの送信としてZeroMQを使用します（Stormは、バージョン0.9からの送信モジュールとして、ZeroMQとNettyの両方をサポートしています）。
ActiveMQ
ActiveMQはApacheのサブプロジェクトです。ZeroMQと同様に、エージェントとピアツーピアテクノロジーを使用してキューを実装できます。同時に、RabbitMQと同様に、少量のコードで高度なアプリケーションシナリオを効率的に実装できます。
カフカ/ジャフカ
Kafkaは、Apacheのサブプロジェクトであり、高性能なクロスランゲージ分散パブリッシュ/サブスクライブメッセージキューイングシステムです。Jafkaは、KafkaのアップグレードバージョンであるKafka上でインキュベートされます。これには次の特性があります。高速永続性、O（1）オーバーヘッドでのメッセージ永続性、共通サーバーで10W /秒のスループット率に達する高スループット、完全分散システム、ブローカー、プロデューサー、およびコンシューマーはすべて、自動的に分散およびロードバランシングを自動的にサポートし、Hadoopデータの並列ロードをサポートします。ログデータおよびHadoopなどのオフライン分析システムでは、リアルタイム処理の制限が必要なため、これは実行可能なソリューションです。 。Kafkaは、Hadoopの並列ロードメカニズムを通じてオンラインとオフラインのメッセージ処理を統合します。ActiveMQと比較すると、Apache Kafkaは非常に軽量なメッセージングシステムであり、非常に優れたパフォーマンスに加えて、適切に機能する分散システムでもあります。