カフカ入門知識のまとめ

Kafka概述

Kafkaは、パブリッシュ/サブスクライブモデルに基づく分散メッセージキュー（メッセージキュー）であり、主にビッグデータのリアルタイム処理で使用されます。

メッセージキュー

メッセージキューを使用する利点。

• デカップリングを
  使用すると、同じインターフェイス制約に準拠していることを確認する限り、両側の処理を個別に拡張または変更できます。

• 回復可能性
  システムの一部に障害が発生しても、システム全体に影響を与えることはありません。メッセージキューはプロセス間の結合を減らすため、メッセージ処理プロセスがハングした場合でも、システムが復元された後でも、キューに追加されたメッセージを処理できます。

• バッファリング、
  ピークカット、およびバレーレベリングは、システムを通過するデータフローの速度を制御および最適化し、本番メッセージと消費メッセージの処理速度間の不整合を解決するのに役立ちます。

• 柔軟性とピーク処理能力
  トラフィックが急増した場合でも、アプリケーションは引き続き機能する必要がありますが、そのようなバーストトラフィックは一般的ではありません。そのようなピーク訪問に対処できるようにするためにいつでもリソースを投資することは間違いなく大きな無駄です。メッセージキューを使用すると、主要なコンポーネントが突然のアクセスプレッシャーに耐えることができ、突然の過負荷の要求によって完全に崩壊することはありません。

• 非同期通信
  多くの場合、ユーザーはメッセージをすぐに処理する必要はありません。メッセージキューは、ユーザーがメッセージをキューに入れることを可能にする非同期処理メカニズムを提供しますが、すぐには処理しません。必要な数のメッセージをキューに入れ、必要に応じて処理します。

メッセージキューの2つの方法

 （1）点对点模式（一对一，消费者主动拉取数据，消息收到后消息清除）消息生产者生产消息发送到Queue中，然后消息消费者从Queue中取出并且消费消息。消息被消费以后，queue中不再有存储，所以消息消费者不可能消费到已经被消费的消息。Queue支持存在多个消费者，但是对一个消息而言，只会有一个消费者可以消费。
 （2）发布/订阅模式（一对多，消费者消费数据之后不会清除消息）消息生产者（发布）将消息发布到topic中，同时有多个消息消费者（订阅）消费该消息。和点对点方式不同，发布到topic的消息会被所有订阅者消费。

これの利点は次のとおりです。

• 複数の消費者をサポートする
• 消費者が消費速度を決定しますが、これのデメリットはサービスを維持する必要があることです。長いポーリングは、メッセージキューにメッセージがあるかどうかを監視します。これはリソースの浪費です。

カフカとは何ですか？

Kafkaは分散データストリーミングプラットフォームです。
ストリーミングコンピューティングでは、Kafkaは一般的にデータのキャッシュに使用され、SparkはKafkaデータを消費することによって計算を実行します。

• Apache Kafkaは、Scalaで記述されたオープンソースのメッセージングシステムです。これは、Apache SoftwareFoundationによって開発されたオープンソースのメッセージングシステムプロジェクトです。
• KafkaはもともとLinkedInによって開発され、2011年の初めにオープンソースになりました。2012年10月に
  ApacheIncubatorを卒業しました。このプロジェクトの目標は、リアルタイムデータを処理するための、統合された高スループットで待機時間の短いプラットフォームを提供することです。
• Kafkaは分散メッセージキューです。Kafkaは、メッセージが保存されるときにトピックに従ってメッセージを分類します。送信者はプロデューサー、メッセージの受信者はコンシューマーと呼ばれます。また、Kafkaクラスターは複数のKafkaインスタンスで構成され、各インスタンス（サーバー）はブローカーと呼ばれます。 。
• Kafkaクラスターとコンシューマーはどちらも、システムの可用性を確保するために、いくつかのメタ情報を格納するためにzookeeperクラスターに依存しています。

カフカの特徴

• メッセージキューや商用メッセージングシステムと同様に、Kafkaはストリーミングデータの公開とサブスクライブを提供します
• Kafkaは、ストリーミングデータを保存するための耐久性のあるフォールトトレラントな方法を提供します
• Kafkaは優れたパフォーマンスを発揮し、ストリーミングデータをタイムリーに処理できます
• Kafkaのメインクラスターモードは、複数のデータセンターにまたがることができる1つ以上のサーバーで実行されます
• Kafkaクラスターは、Kafkaではトピックと呼ばれるカテゴリレコードに従ってデータを格納します
• 各レコードは、キー、値、およびタイムスタンプで構成されます

キーコンセプト

ブローカー：kafkaサーバーはブローカーです。クラスターは複数のブローカーで構成されています。
トピック：トピックはデータトピックです。Kafkaは、ビジネスシステムに応じて、さまざまなトピックにさまざまなデータを保存することをお勧めします。Kafkaのトピックは常にマルチサブスクライバーモデルであり、トピックには1人以上のコンシューマーがデータをサブスクライブすることができます。大きなトピックは、複数のkafkaブローカーに配布および保存できます。トピックはデータベース内のライブラリと比較できます

パーティション：各トピックは複数のパーティションを持つことができます。パーティションの設計を通じて、トピックを継続的に拡張できます。つまり
、トピックの複数のパーティションが分散され、複数のブローカーに格納されます。さらに、トピックは、パーティション化によって複数のコンシューマーによって消費される可能性があります。並列処理を実現するために！パーティションはデータベース内のテーブルと比較できます！
Kafkaは、メッセージがパーティション内の順序でコンシューマーに送信されることを保証するだけであり、トピック全体（複数のパーティション間）の順序を保証するものではありません。
オフセット：データは、時系列でパーティションの構造化コミットログに継続的に追加されます！各パーティションに格納されているレコードは順番に並んでおり、順番は不変です。この順序は、オフセットと呼ばれるIDによって一意に識別されます。したがって、offsetは、順序付けられた不変の
プロデューサーと見なすこともできます。メッセージプロデューサーは、Kafkaブローカーにメッセージを送信するクライアントです。プロデューサーは、トピックの指定されたパーティションにレコードを割り当てる責任があります。
コンシューマー：メッセージコンシューマー、kafkaブローカーからメッセージを取得するクライアント。各コンシューマーは、データを読み取るためのオフセットを維持する必要があります。オフセットは、バージョン0.9より前のデフォルトではZookeeperに保存され、0.9以降はデフォルトでKafkaの「__consumer_offsets」トピックに保存されます。
コンシューマーグループ：トピックには複数のコンシューマーグループを含めることができます。トピックメッセージはすべてのCGにコピーされます（実際にはコピーされませんが、概念的には）が、各パーティションはCG内の1人のコンシューマーにのみメッセージを送信します。各コンシューマーは、コンシューマーグループ名を使用して識別します。同じグループ内の異なるコンシューマーインスタンスは、複数のプロセスまたは複数のマシンに分散できます

kafka的持久化

Kafkaクラスターは、公開されたすべてのレコード（消費されたかどうかに関係なく）を保持し、構成可能なパラメーター（保持期間）によって制御されます。たとえば、保持ポリシーが2日に設定されている場合、レコードは解放されてから2日以内であればいつでも消費できます。2日後、レコードはクリアされ、ディスク領域が解放されます。
Kafkaのパフォーマンスはデータサイズとは関係がないため、データを長期間保存しても問題ありません。

カフカコピーメカニズム

ログパーティション（分散）はKafkaクラスターサーバー上にあります。各サーバーは、データと要求を処理するときにこれらのパーティションを共有します。各パーティションは、フォールトトレランスを確保するために、構成されたサーバーにバックアップされます。
各パーティションには、「リーダー」として1台のサーバーがあり、フォロワーとして0台以上のサーバーがあります。リーダーサーバーはパーティションへのすべての読み取りおよび書き込み要求を処理しますが、フォロワーはリーダー上のデータを受動的に同期するだけで済みます。リーダーがダウンすると、フォロワーのサーバーが自動的に新しいリーダーになります。このメカニズムにより、データに複数のコピーがあることを確認できるだけでなく、可用性の高いメカニズムを実現できます。
セキュリティの考慮事項/負荷分散の考慮事項に基づいて、各パーティションのリーダーとフォロワーはブローカーに割り当てられません。

Kafkaインフラストラクチャ

Kafkaワークフローとファイルストレージメカニズム

Kafkaのメッセージはトピックごとに分類されます。プロデューサーはメッセージを生成し、コンシューマーはメッセージを消費します。これらはすべてトピック指向です。
トピックは論理的な概念であり、パーティションは物理的な概念です。各パーティションはログファイルに対応し、ログファイルにはプロデューサーによって生成されたデータが格納されます。プロデューサーによって生成されたデータは、ログファイルの最後に継続的に追加され、各データには独自のオフセットがあります。コンシューマーグループの各コンシューマーは、消費したオフセットをリアルタイムで記録するため、エラーが復元されたときに、最後の場所から消費を継続できます。

プロデューサーによって生成されたメッセージは常にログファイルの末尾に追加されるため、ログファイルが大きすぎるとデータの配置が非効率になるのを防ぐために、Kafkaは断片化とインデックス作成のメカニズムを採用して各パーティションを複数のセグメントに分割します。

カフカプロデューサー

カフカパーティションの
理由：

• クラスター内で拡張すると便利です。各パーティションは、それが配置されているマシンに適応するように調整でき、トピックは複数のパーティションで構成できるため、クラスター全体を任意のサイズのデータ​​に適応できます。
• パーティション単位で読み取りと書き込みができるため、同時実行性を向上させることができます。
  ゾーニングの原則：
• パーティションを指定する場合は、指定した値を直接パーティション値として使用します。
• パーティション値が指定されていないが
  キーがある場合、キーのハッシュ値とトピックのパーティション番号は、残りを取得してパーティション値を取得することによって取得されます。
  パーティション値もキー値もない場合は、整数は最初の呼び出しでランダムに生成され（後続の各呼び出しはこの整数で増分します）、この値の残りとトピックで使用可能なパーティションの総数を取得して、パーティション値を取得します。これは、ラウンドと呼ばれることがよくあります。 -ロビンアルゴリズム。

データの信頼性保証

プロデューサーから送信されたデータを指定されたトピックに確実に送信できるようにするには、トピックの各パーティションは、プロデューサーから送信されたデータを受信した後、プロデューサーにack（確認確認）を送信する必要があります。プロデューサーがackを受信した場合、次のラウンドを送信します。それ以外の場合は、データを再送信します。

• ISR
  リーダーは、動的同期レプリカセット（ISR）を維持します。これは、リーダーと同期されるフォロワーセットを意味します。ISRのフォロワーがデータの同期を完了すると、リーダーはフォロワーにackを送信します。フォロワーがリーダーとデータを長時間同期しない場合、フォロワーはISRから追い出されます。時間のしきい値は、replica.lag.time.max.msパラメーターによって設定されます。リーダーが失敗した後、新しいリーダーがISRから選出されます

• ack応答メカニズム

重要度の低い一部のデータの場合、データの信頼性要件はそれほど高くなく、少量のデータ損失も許容できるため、ISRのすべてのフォロワーが正常に受信するのを待つ必要はありません。
そのため、Kafkaはユーザーに3つの信頼性レベルを提供します。ユーザーは、信頼性と遅延の要件に応じて、次の構成を選択できます。Acks
パラメーター構成：
acks：
0：プロデューサーはブローカーのackを待機しません。この操作は最小の遅延を提供します。ブローカーはそれを受信するとすぐに戻り、ディスクに書き込まれません。ブローカーに障害が発生すると、データが失敗する可能性があります。失われる;
1：プロデューサーブローカーのackを待っていると、パーティションのリーダーは配置が成功した後にackを返します。フォロワーの同期が成功する前にリーダーが失敗すると、データが失われます;
-1（すべて）：プロデューサーブローカーのackを待ち、パーティションのリーダーとフォロワーがすべて配置されます。成功した場合にのみackを返します。ただし、フォロワーの同期が完了した後、ブローカーがackを送信する前にリーダーに障害が発生すると、データの重複が発生します。isrにリーダーが1つしかない場合は、リーダーが1であっても、データが失われる可能性があることに注意してください。

トラブルシューティングの詳細

LEO：各コピーの最大オフセットを
指します。HW：消費者が見ることができる最大オフセットを指し、ISRキュー内の最小LEOを指します。
（。1）障害
後の障害フォロワーフォロワーは一時的にISRをキックし、フォロワーまで回復し、フォロワーHWはローカルディスクの最後のレコードを読み取り、ログファイルはHWから取り出された部分よりも高くなります。
リーダーとの同期を開始します。フォロワーのLEOがパーティションのHW以上になった後、つまりフォロワーがリーダーに追いついた後、ISRに再度参加できます。
（2）リーダーの失敗リーダーが失敗した後、
ISRから新しいリーダーが選択されます。その後、複数のコピー間のデータの整合性を確保するために、残りのフォロワーは最初にログファイルをHWカットの部分よりも高く設定します。オフにしてから、新しいリーダーからのデータを同期します。

正確に一度のセマンティクス

• 最大で1回：最大で1回
• 少なくとも一度は：
• 持っていると一度だけ：ちょうど一度

-1を使用すると、データが失われないことは保証できますが、データが繰り返されないことは保証できません。1回だけであることを確認する必要がある場合は、消費者が消費した後データ、データの重複排除のためのコードを開発する必要があり、トピック複数のコンシューマーグループをサブスクライブでき、サブスクライブするときに各グループを重複排除する必要があります...

さらに重要なメッセージについては、セマンティクスを1回だけ確認する必要があります。つまり、各メッセージが送信され、1回だけ送信されるようにする必要があります。

バージョン0.11以降、Kafkaプロデューサーはべき等メカニズム（idempotent）を導入し、acks = -1の場合に少なくとも1回のセマンティクスを使用して、プロデューサーからブローカーへのセマンティクスを1回だけ達成しました。

カフカの消費者

消費者は、ブローカーからデータを読み取るために、プルモードを使用しています。メッセージ送信レートはブローカーによって決定されるため、
プッシュモデルを異なる消費レートのコンシューマーに適応させることは困難です。その目標は、メッセージをできるだけ早く配信することですが、これにより、消費者がメッセージを処理するのに遅すぎる可能性があります。典型的な症状は、サービス拒否とネットワークの輻輳です。プルモードでは、コンシューマーの消費容量に応じて適切な速度でメッセージを消費できます。欠点
プルモードでは、カフカがデータがない場合、消費者はループに陥ると、常に空のデータを返すことです。これに応じて、Kafkaコンシューマーは、データを消費するときに期間パラメーターのタイムアウトを渡します。現在消費できるデータがない場合、コンシューマーは一定期間待機してから戻ります。この期間はタイムアウトです。

パーティション割り当て戦略

Kafkaには2つの割り当て戦略があります。1つはRoundRobinで、もう1つはRangeです。

• RoundRobinの使用はグループ指向であり、考えられる問題は、同じグループ内の異なるコンシューマーが異なるトピックにサブスクライブできることです。これはポーリング戦略であるため、この構成は無効になります。
• 範囲がサブジェクト指向であることを考慮すると、この戦略の問題は、不均一な負荷が発生する可能性があることです。

RoundRobinの使用はグループ指向です。結果として生じる可能性のある問題は、同じグループ内の異なるコンシューマーが異なるトピックをサブスクライブできることです。ポーリング戦略が採用されているため、この構成は無効になります。
範囲がトピック指向であることを考慮すると、これ戦略の問題は、負荷が不均一になる可能性があることです。

• 同じ消費者グループに消費者を追加する
• 消費者は、シャットダウンやクラッシュなど、現在所属している消費者グループを離れます
• サブスクライブされたトピックの新しいパーティション

オフセットの維持（強調）

• オフセットが格納される場所を理解する必要があります。0.9より前のオフセットはデフォルトでzkに格納され、0.9以降はデフォルトでkafkaのテーマに格納されます。
• オフセットはコンシューマーとは関係ありませんが、コンシューマーグループ、トピック、パーティションとは関係があります。コンシューマーと関係がある場合、コンシューマーが電話を切った場合、オフセットは失われたり変更されたりすると考えられます。明らかに、それは不合理です。つまり、コンシューマーが電話を切ったときに、コンシューマーグループを再パーティション化します。このパーティションは新しいコンシューマーに割り当てられる場合がありますが、このオフセット後もパーティション化は継続されます。

Kafkaはデータを効率的に読み書きします

1）
Kafkaのプロデューサーの本番データをディスクに順次書き込みます。ログファイルに書き込む必要があります。書き込みプロセスは、ファイルの最後に追加することで、順次書き込みです。公式ウェブサイトには、同じディスクに最大600M / sのシーケンスで書き込むことができるが、ランダムに100K / sしか書き込むことができないというデータがあります。これは、ディスクの機械的メカニズムに関連しています。シーケンシャル書き込みが高速である理由は、ヘッドアドレス指定時間を大幅に節約できるためです。
2）ゼロコピー技術

KafkaでのZookeeperの役割

Kafkaクラスター内のブローカーがコントローラーとして選出されます。選出メカニズムはリソースを取得することです。最初に開始するのはコントローラーです。クラスターブローカーのオンラインとオフラインの管理、すべてのパーティションコピーの割り当てを担当します。トピック、およびリーダー選挙。
コントローラーの管理作業はZookeeperに依存しています

Kafka的API

プロデューサーAPI

メッセージ送信プロセス
Kafkaのプロデューサーはメッセージを非同期で送信します。メッセージ送信のプロセスには、メインスレッドと送信者スレッドの2つのスレッドと、スレッド共有変数のRecordAccumulatorが含まれます。メインスレッドはメッセージをRecordAccumulatorに送信し、送信者スレッドは継続的にRecordAccumulatorからメッセージをプルして、Kafkaブローカーに送信します。
関連パラメーター：

• batch.size：送信者は、データがbatch.sizeに蓄積された後にのみデータを送信します。
• linger.ms：データがbatch.sizeに達しない場合、送信者はlinger.timeを待った後にデータを送信します。

コンシューマーAPI

Kafkaではデータが永続的であるため、消費者のデータ消費の信頼性を保証するのは非常に簡単であり、データの損失を心配する必要はありません。
消費者は消費プロセス中に停電やダウンタイムなどの障害を経験する可能性があるため、消費者が回復した後、障害前の場所から消費を継続する必要があるため、消費者は消費を相殺するためにリアルタイムで記録する必要があります。障害が回復した後も消費を続けることができます。
したがって、オフセットの維持は、消費者がデータを消費するときに考慮しなければならない問題です。