I.はじめに
この記事では、主にKafkaのアーキテクチャとアプリケーションのシナリオを紹介します。
2.カフカの紹介
2.1カフカの紹介
Kafkaは、高レベルのスケーラビリティと高スループットを備えたScalaを使用してLinkedInによって作成された分散メッセージングシステムです。
Kafkaは、保存時にトピックに従ってメッセージを分類します。メッセージの送信者はプロデューサーになり、メッセージの受信者はコンシューマーになります。さらに、kafkaクラスターは複数のkafkaインスタンスで構成され、各インスタンス（サーバー）はブローカ。
Kafkaクラスター、プロデューサー、コンシューマーの両方が、システムの可用性を確保し、クラスターのメタ情報を保存するために動物園の飼育係に依存しています。
ApacheKafka®は分散ストリーム処理プラットフォームです。ストリーム処理プラットフォームの機能は次のとおりです。
（1）ストリーミングレコードをパブリッシュおよびサブスクライブできます。この側面は、メッセージキューまたはエンタープライズメッセージングシステムに似ています。
（2）ストリーミングレコードを保存でき、フォールトトレランスが向上します。
（3）ストリーミングレコードは、生成時に処理できます。
Kafkaはどのようなシナリオに適していますか？
（1）システム間またはアプリケーション間でデータを確実にフェッチできるリアルタイムストリーミングデータパイプラインを構築します。（メッセージキューに相当）
（2）リアルタイムストリーミングアプリケーションを構築して、これらのストリーミングデータを変換または影響を与えます。
Kafkaの主な機能
（1）Kafkaは1つ以上のサーバー上でクラスターとして実行されます
（2）Kafkaは保存されたストリームデータをトピックごとに分類します
（3）各レコードにはキー、値、タイムスタンプ（タイムスタンプ）が含まれます）
2.2分散カフカに基づく
通常のメッセージキューから分散メッセージキューkafkaまで、最大の違いは動的拡張をサポートしていることです。
rabbitmqとkafkaを比較すると、類似点と相違点は次のとおりです。
類似点：kafkaとrabbitmqはどちらもストレージキュー
です。相違点：
（1）消費単位が異なり
ますrabbitmqでは、メッセージごとに、コンシューマーはメッセージを1回しか消費できませんが、メッセージは同時に複数のコンシューマーに送信できます。 kafkaでは、コンシューマーグループはメッセージを1回しか消費できませんが、このメッセージを複数のコンシューマーグループに送信して同時に消費することができます
（2）
rabbitmqでは、メッセージの消費が異なり、正常に消費されたackのメッセージは自動的に削除され、kafkaでは、メッセージが正常に消費された後は削除されず、ただコンシューマーのオフセットを移動し（コンシューマーのオフセットはzkに保存されます）、kafkaはデフォルトで7日間保存されます（メッセージにはtimestamp属性があり、メッセージの保存時間を制御するために使用できます）。
（3）メッセージは、rabbitmqのさまざまな
メッセージで構成されます= routingkey + headers（properties）+ kafkaのペイロード
メッセージ=構成ファイル内のログの場所（3つのファイル）= index（key）+value+タイムスタンプ
index/keyは、並べ替え（順次消費））またはインデックス。デフォルトのインデックス/キーを指定しない場合、値はメッセージ本文であり、タイムスタンプはメッセージを物理的に削除するために使用されます（kafkaのデフォルトのメッセージストレージは7日です。オフセットは消費時にのみ移動され、メッセージは削除されないため）
（4）
Rabbitmqは交換スイッチとキューで構成されます。Exchangeはメッセージを保存しない抽象的な概念です。キューは実際にメッセージを保存する実際の概念とコンポーネントです。Kafkaはトピック
とパーティションで構成されます。トピックは交換に似ており、保存されません。ただし、コンシューマーはトピックを指定してデータを消費したいので、トピックは対応するパーティションからコンシューマーにデータをフェッチします。パーティションはrabbitmqのキューに似ており、実際にメッセージを格納するコンポーネントです。
質問：kafkaが少なくとも1つのコンシューマーグループを必要とするのに、rabbitmqの最小単位が1つのコンシューマーであるのはなぜですか？
回答：Kafkaは自然に分散されているため、n個のブローカーにはn個のパーティションがあります。
質問：Kafkaはどのように順次消費を実装しますか？
回答：同じパーティション内で、すべてのメッセージのキーが空であるか、すべてのメッセージのキーが同じです。
例1：kafkaの場合、コンシューマーは最初または最後からメッセージを消費できますが、古いものから新しいものへのメッセージのみを消費できます。
eg2：kafkaの場合、トピックの数が指定されていない場合、デフォルトは3です。
3.カフカアーキテクチャ
3.1メッセージの生成と消費
3.1.1メッセージの生成と消費のモデル
Kafkaは、他のメッセージキューと同様に、次のように非常に単純なメッセージの生成と消費のモデルを持っています。
サーバー側（ブローカー）：プロデューサーから送信されたメッセージを受信し、これらのメッセージをサーバーのキューにルーティングするために使用され
ます。 queue
プロデューサー（プロデューサー）でメッセージを要求するクライアントアプリケーション：ブローカーにメッセージを公開するクライアントアプリケーション
3.1.2Kafka消費単位は消費者グループです
kafkaでは、最も重要なコンポーネントはトピックですが、このトピックはデータを格納しません。実際のストレージデータはパーティションであり、トピックはrabbitmqの交換に似ています。トピックはデータを格納しないため、その役割は何ですか？トピックの唯一の役割はデータトピックです。これは、データレコードが公開され、ビジネスシステムを区別するために使用できます（テスト用にテスト、本番用にプロという名前）。Kafkaのトピックは常にマルチサブスクライバーモードです。つまり、トピックには1人以上のコンシューマーがデータをサブスクライブすることができます。つまり、コンシューマーグループの各コンシューマーは、直接パーティションではなく、メッセージを要求するトピックを探しています。トピックの役割は、パーティション内のメッセージをコンシューマーに送信することです。
kafkaの場合、kafkaは自然に分散され、消費者グループの概念が含まれるため、主にメッセージの消費に応じて、生産者の生産データをkafkaに格納するのは比較的簡単です。
たとえば、message1 message2 message3が生成され、partition1 partition2 partition3に格納されます。partitionはキューに相当します。3つのコンシューマーがあります。どのように消費しますか？これには、コンシューマーグループの確率が含まれます。コンシューマーグループの誕生の意味は、コンシューマーグループがすべてのパーティション（ここでは3つのパーティション）に格納されているすべてのメッセージを消費することです。メッセージは、コンシューマーグループが1回だけ消費できます。コンシューマーが消費できるメッセージは、コンシューマーグループがどのように割り当てられているかによって異なります。
コンシューマー1が1つのコンシューマーグループに属し、コンシューマー2とコンシューマー3が別のコンシューマーグループに属する場合、コンシューマー1はmessage1、message2、message3の3つのメッセージを消費できます。Consumer2とconsumer3はmessage1、message2、message3を一緒に消費します。 1つのコンシューマーグループ。かつて、メッセージがコンシューマーグループ内のどのコンシューマーによって消費されるかを決定するのはプログラマーの責任ではありません。
コンシューマー1が1つのコンシューマーグループに属し、コンシューマー2が別のコンシューマーグループに属し、コンシューマー3が3番目のコンシューマーグループに属する場合、各コンシューマーは3つのメッセージを消費できます。
クロスカバレッジも可能です。consumer1とconsumer2が1つのコンシューマーグループに属し、consumer2とconsumer3が別のコンシューマーグループに属する場合、consumer1とconsumer2は3つのメッセージを消費でき、consumer2とconsumer3はこれらの3つのメッセージを消費できます。
これがKafkaコンシューマーグループの概念です。最も重要な方法は、コンシューマーグループがすべてのパーティションに格納されているすべてのメッセージを消費し、メッセージはコンシューマーグループによって1回だけ消費されるということです。消費者とパーティションの関係：
ケース1：通常の状況では、コンシューマーグループの3つのコンシューマーが3つのパーティションに対応し、各コンシューマーが1つのパーティションを消費します。
ケース2：コンシューマーグループのコンシューマーがハングした場合、コンシューマーグループその中で2つのコンシューマーが3つのパーティションに対応します。 、次に、コンシューマーの1つが2つのパーティションを消費する
場合があります。ケース3：パーティションが3つだけで、コンシューマーグループに4つのコンシューマーがある場合、1つのコンシューマーグループ、4つのコンシューマーが3つのパーティションに対応し、1つのコンシューマーがアイドル状態になります。
ケース4：もう1つのコンシューマーグループを追加すると、新しいコンシューマーグループか元のコンシューマーグループかに関係なく、2つのコンシューマーグループが3つのパーティションに対応します。コンシューマーグループはトピックのすべてのデータを消費できます（理由：コンシューマーグループは論理的に独立しています）。
コンシューマーグループの本質：コンシューマーグループはマルチスレッドの概念です。つまり、複数のスレッドがすべてのメッセージ（各パーティションパーティションのメッセージの合計）を消費し、コンシューマーインスタンスは複数のプロセスまたは複数のプロセスに分散できます。マシン。
（1）消費者グループの概念が必要です。消費者が1人の場合、消費者グループの消費者は1人だけであり、消費者がN人の場合、消費者グループの消費者はN人だけです。
（2）コンシューマーグループは、パーティションのすべてのプライマリパーティションのメッセージを消費する必要があります。グループ内に十分なコンシューマーがない場合、コンシューマーグループはパーティション上のメッセージを消費する必要があるため、1つのコンシューマーが複数のパーティションを消費する必要があります。それ以上ある場合は、何もする必要がない人もいます。
（3）同じコンシューマーグループで、メッセージは1回だけ消費されます。
コンシューマーはコンシューマーグループ名で識別され、トピックに公開された各レコードは、サブスクライブしているコンシューマーグループのコンシューマーインスタンスに割り当てられます。コンシューマーインスタンスは、複数のプロセスまたは複数のマシンに分散できます。すべてのコンシューマーインスタンスが同じコンシューマーグループにある場合、メッセージログは各コンシューマーインスタンスに負荷分散されます。すべてのコンシューマーインスタンスが異なるコンシューマーグループにある場合、各メッセージレコードはすべてのコンシューマープロセスにブロードキャストされます。以下に示すように：
3.1.3 Kafkaは、パーティションのプライマリパーティションからのメッセージのみを消費します
Kafkaのメッセージはパーティションに保存されますが、各パーティションにはマスターパーティションとn個のスレーブパーティションを含むバックアップがありますが、プロデューサーがKafkaにデータを書き込むと、マスターパーティションとスレーブパーティションのメッセージに一貫性がなくなります。以下に示すように
上の写真は012 3 4 5 6 7 8 9 10 11 12を示しています。この写真が読者に伝えたいのは、メッセージが3つのパーティションに保存されている場合、データに一貫性がないことです。データを取得すると、データが欠落したり重複したりしますか？答えはノーです。消費者がメッセージのトピックを探しているとき、メッセージのパーティションを直接探すのではなく、トピックがプライマリパーティションから消費者へのデータを毎回見つけるからです。つまり、コンシューマーはプライマリパーティションからのメッセージのみを消費し、スレーブパーティションはプライマリパーティションからのメッセージのみを同期します。
kafkaのこのパーティションのデータの不整合は、rabbitmqのクラスターの通常モードと同じであり、データは不整合であり、rabbitmqのミラーモードのデータは整合性があります。
概要：kafkaでは、プロデューサーとコンシューマーがメインパーティションの読み取りと書き込みを行い、スレーブパーティションが生成と消費を行わず、kakfaがメカニカルハードディスクにシーケンシャル読み取りと書き込みを使用するため、コンシューマーグループはメインパーティションのみを消費します。アドレス指定時間は必要ありません。速度はランダムな読み取りと書き込みに近いです。スレーブパーティションが固定戦略に従ってマスターパーティションのデータを同期している限り、マスターパーティションがダウンすると、zookeeperの調整の下で、新しいパーティションが生産と消費のために選択されます。
3.1.4消費者グループ内の各消費者のオフセット
オフセットについて
（1）各消費者は互いに独立していて相互に影響を及ぼさないオフセットを持っています
（2）各消費者のオフセットは動物園の飼育係に保存されているため、消費者がダウンしても消費を続けることができます次回は、以前の消費場所がオフセットされているため、飼育係はそれを記録し、消費者が再起動した後、自分のオフセットに従って消費します。
同じコンシューマーグループであっても、consumer1とconsumer2にはそれぞれオフセットがあります。各コンシューマーがアクセスする場合は、zookeeperからオフセットを削除する必要があります。コンシューマーが初めてアクセスする場合、以下に示すように、zookeeperは0から確立されます。 ：
一般的に、n個のブローカーにはn個のパーティションがあります。すべてのブローカーがダウンしない限り、データが失われることはなく、ディスクの永続性が保証されます。
例：オフセットは、プロデューサーではなく、コンシューマーにのみ役立ちます。
例：コンシューマーのオフセットは、zookeeperに格納されますが、zookeeperは読み取り専用であり、書き込まれません。これは、zookeeperの同時書き込みパフォーマンスが低いという問題を解決するためです。したがって、zookeeperはデータを保存しませんが、プロデューサーによって生成されたデータを書き込む必要があり、kafkaのパーティションに配置する必要があります。
3.1.5まとめ
質問：N個のコンシューマーはどのようにM個のパーティションを消費しますか？
回答：コンシューマーグループの導入により、消費方法の問題が解決されます。コアは、コンシューマーグループがすべてのパーティションメッセージを完全に消費する必要があり、メッセージはコンシューマーグループ内のコンシューマーのみが消費できることです。同じコンシューマーグループ内で、メッセージが2回消費されることはなく、繰り返し消費されることもありません。
ケース1：通常の状況では、コンシューマーグループの3つのコンシューマーが3つのパーティションに対応し、各コンシューマーが1つのパーティションを消費します。
ケース2：コンシューマーグループのコンシューマーがハングした場合、コンシューマーグループその中で2つのコンシューマーが3つのパーティションに対応します。 、次に、コンシューマーの1つが2つのパーティションを消費する
場合があります。ケース3：パーティションが3つだけで、コンシューマーグループに4つのコンシューマーがある場合、1つのコンシューマーグループ、4つのコンシューマーが3つのパーティションに対応し、1つのコンシューマーがアイドル状態になります。
ケース4：もう1つのコンシューマーグループを追加すると、新しいコンシューマーグループか元のコンシューマーグループかに関係なく、2つのコンシューマーグループが3つのパーティションに対応します。コンシューマーグループはトピックのすべてのデータを消費できます（理由：コンシューマーグループは論理的に独立しています）。
質問：消費されたメッセージは削除されますか？
回答：消費されたメッセージはオフセットを移動するだけで、削除せず、デフォルトで7日間保存されます（メッセージ本文のタイムスタンプを使用して、メッセージが保存されている期間を確認してください）。オフセットはzookeeperに保存されます。これは、zookeeperがデータの一貫性を確保でき、オフセットを特定のサーバーのディスクに保存できないためです。
質問：Kafkaは、メッセージの読み取りと書き込み、およびメッセージの削除のためにディスク全体をスキャンする必要がありますか？
回答：いいえ、それぞれにタイムスタンプフィールドがあります。Kafkaはシーケンシャルな読み取りと書き込みを使用して、メッセージの削除が非常に便利であることを確認します。
質問：複数のパーティションがあります。プロデューサーはkafkaにデータを書き込み、データの不整合があります。メッセージの消費が繰り返されたり、失われたりしないようにするにはどうすればよいですか。
回答：消費されたメッセージが複製またはリークされないようにするために、プライマリパーティションのみが消費されます。パーティションにはマスタースレーブの区別があります。プライマリパーティションのみが消費され、セカンダリパーティションのみが同期されるため、消費されたメッセージは複製またはリークされません。
質問：カフカの消費順序は何ですか？
回答：kakfaは現在のヘッドまたは現在のテールから消費できますが、古いものから新しいものへ、つまり古いものから新しいものへとしか消費できず、その逆はできません。
3.2パーティションのバックアップとマスターの選択
以下に示すように、各パーティションはレプリケーションとして他のサーバーにもレプリケートされます。これは冗長バックアップ戦略です。
パーティションのバックアップには4つの特徴があります
（1）同じブローカーで同じパーティションの複数のレプリケーションは許可されません
（2）各パーティションのレプリケーションには1つのリーダーと0人以上のフォロワーがあります
（3）リーダーはすべてのパーティションを処理します読み取りおよび書き込み要求の場合、フォロワーはデータを受動的に複製するだけです
（4）リーダーがダウンした後、新しいリーダーがフォロワーから選出されます
パーティションパーティションはクラスター内の複数のサーバーに分散され、各サーバーは割り当てられたパーティションを処理します。また、構成に応じて、バックアップのフォールトトレランスのために各パーティションを他のサーバーに複製することもできます。各パーティションには、1人のリーダーと0人以上のフォロワーがいます。リーダーはこのパーティションのすべての読み取りおよび書き込み要求を処理し、フォロワーはデータを受動的に複製します。
リーダーが倒れた場合、別のフォロワーが新しいリーダーとして選出されます。マスターの選択は、zookeeperミドルウェアで行う必要があります。zkがマスターを選択する場合、スレーブパーティションのデータはダウンマスターパーティションのデータに最も近く、同期時間はマスターパーティションに最も近くなります。マスターパーティションとして選択されます。サーバーは、あるパーティションのリーダーであり、同時に別のパーティションのフォロワーである場合があります。これにより、負荷を分散し、すべてのリクエストが1つまたは少数のサーバーによって処理されるのを防ぐことができます。
3.3高度な機能
3.3.14つのコアAPI
Producer API
を使用すると、アプリケーションはデータのストリームを1つ以上のKafkaトピックに公開できます。
Consumer API
を使用すると、アプリケーションは1つ以上のトピックにサブスクライブし、それらに公開されたストリーミングデータを処理できます。
Streams API
を使用すると、アプリケーションをストリームプロセッサとして機能させ、1つ以上のトピックによって生成された入力ストリームを消費し、1つ以上のトピックへの出力ストリームを生成して、入力ストリームと出力ストリームに対して効率的な変換を実行できます。
Connector API
を使用すると、Kafkaトピックを既存のアプリケーションまたはデータシステムに接続する再利用可能なプロデューサーまたはコンシューマーを構築および実行できます。たとえば、リレーショナルデータベースに接続し、テーブルへのすべての変更をキャプチャします。
Kafkaの4つのコアAPI関係は次のとおりです。
上の図は、Kafkaでは、クライアントとサーバー間の通信がシンプルで高性能な言語に依存しないTCPプロトコルを介して行われることを示しています。つまり、Kafkaはjavaおよびscalaと混合でき、言語に依存しないtcp / ipネットワーク通信。このプロトコルはバージョン管理されており、古いバージョンとの下位互換性を維持しています。Kafkaは複数の言語でクライアントを提供します。
上の図のコネクタは、kafkaおよびmysqlredisなどの他の接続を表しています。
3.3.2ウェーブを保存して再送信する
プロデューサーがkafkaにメッセージを送信すると、プロデューサーは、送信されていないデータを記録するために各パーティションのバッファーを維持します。各バッファーのサイズは、batch.sizeで指定されます。デフォルト値は16k、つまり、以下に示すように、データは16Kがいっぱいになるまで待機する必要があります。送信するだけで、ウェーブを保存して再度送信し、ネットワークパフォーマンスの消費を削減します。
例：パラメータlinger.msもあります。これは、batch.sizeに到達する前にバッファ内のデータが待機する必要がある時間を示します。
3.3.3通常の消費パターンと高度な消費パターン
一般的な消費モード：Kafka Simple Consumer
Simple Cnsumerはkafka.javaapi.consumerパッケージにあり、負荷分散とフォールトトレランス機能を提供していません。データを取得するには、毎回topic、partition、offset、fetchSizeを指定する必要があります。
高度な消費モード：高レベルの消費者
次の図に示すように、クライアントはkafkaブローカーの例外を透過的に処理し、コンシューマーパーティションを透過的に切り替え、ブローカーと対話して、コンシューマーグループレベルでの負荷分散を実現します。
補助的な理解：一般的な消費モードはアセンブリ言語のC言語に似ており、何もありません。プログラマーはそれを指定する必要があります。高度な消費モードは、多くの準備が整っているJava言語のPython言語に似ており、プログラマーは直接使用できます。
通常、アドバンストコンシューマーモードが使用されます。
3.4カフカの全体的なアーキテクチャ
kafkaの全体的なアーキテクチャについては、トピックとパーティションの2つの最も重要なコンポーネントを知っている限り、以下に示すように、次のことができます。
例：上の図のzookeeperは、各コンシューマーのオフセットを保存するために使用されます。
4.Kafkaアプリケーションのシナリオ
4.1 Kafkaアプリケーションシナリオ：メッセージ
Kafkaは、ほとんどのメッセージングシステムと比較して、さまざまなシナリオ（データプロデューサーの分離、未処理のメッセージのキャッシュ）で使用される従来のメッセージングシステムの優れた代替品です。Kafkaは、スループット、組み込みのパーティショニング、レプリカやフェイルオーバーなどの機能を備えています。大規模なメッセージの処理に適しています。
公式の経験によると、通常、メッセージングはより低いスループットを使用しますが、より低いエンドツーエンドの遅延を必要とする場合があり、kafkaはこの要件を満たすために強力な永続性を提供します。この点で、Kafkaは従来のメッセージングシステム（ActiveMQおよびRabbitMQ）に匹敵します。
4.2 Kafkaアプリケーションシナリオ：Webサイトアクティビティの追跡
kafkaの最初の役割は、ユーザーアクティビティ追跡パイプラインを一連のリアルタイムのパブリッシュ/サブスクライブフィードとして再構築することです。Webサイトアクティビティ（Webブラウジング、検索、またはその他のユーザーアクション）を、アクティビティタイプごとに1つずつ、中心的なトピックに公開します。これらのフィードは、リアルタイム処理、リアルタイムモニタリング、オフライン処理、Hadoopまたはオフラインデータウェアハウスシステムにロードされたデータのレポートなど、さまざまなユースケースを提供します。
各ユーザーがWebを閲覧すると、多くのアクティビティ情報が生成されるため、アクティビティ追跡用のデータ量は非常に多くなることがよくあります。これは非常にkafkaを使用しています。
4.3 Kafkaアプリケーションシナリオ：ログの集計
多くの人が、ログ集計ソリューションの代わりにkafkaを使用しています。ログ集約システムは通常、サーバーから物理ログファイルを収集し、それらを中央システム（おそらくファイルサーバーまたはHDFS）に配置して処理します。
Kafkaは、これらのログファイルから情報を抽出し、それをよりクリーンなメッセージフローに抽象化します。これにより、遅延処理が少なくなり、複数のデータソースと分散データ消費のサポートが容易になります。
ScribeやFlumeのようなログ中心のシステムと比較して、Kafkaは同じ優れたパフォーマンス、優れた耐久性（レプリケーションによる）、および低いエンドツーエンドのレイテンシーを提供します。
4.4 Kafkaアプリケーションシナリオ：ストリーム処理
0.10.0.0以降、kafkaは軽量でありながら強力なストリーム処理をサポートしています。
Kafkaメッセージ処理は複数の段階で構成されています。ここで、生の入力データはkafkaトピックから消費され、さらに消費または後続の処理のために、集約、強化、またはその他の方法で新しいトピックに処理されます。
たとえば、推奨ニュース記事の場合、記事のコンテンツは「記事」トピックから取得できます。その後、コンテンツはさらに処理されて処理済みの新しいコンテンツが取得され、最後にユーザーに推奨されます。この処理は、単一のトピックに関するデータのリアルタイムストリームに基づいています。
Kafka Streamsに加えて、ApacheStormとApacheSamzaも優れたストリーム処理フレームワークです。
4.5 Kafkaアプリケーションシナリオ：イベントコレクション
イベントソーシングは、時間の経過に伴う状態の変化を記録するアプリケーション設計スタイルです。Kafkaは非常に大量のログデータを保存できるため、イベントソーシングベースのアプリケーションを強力にサポートします。
4.6 Kafkaアプリケーションシナリオ：コミットログ
Kafkaは、外部から分散システムにログ送信機能を提供できます。ログは、ノードとアクション間のデータを記録するのに役立ち、再同期メカニズムを使用して、障害が発生したノードからデータを回復できます。Kafkaのログ圧縮機能は、この使用法をサポートしています。これは、ApacheBookKeeperプロジェクトに似ています。
ファイブ、終わり
この記事では、主にKafkaのアーキテクチャとアプリケーションのシナリオを紹介します。
毎日コーディングし、毎日進歩させましょう！！