Kafkaは分散メッセージングエンジンシステムで、メッセージのパブリッシュとサブスクライブのソリューション一式を提供します。

Kafkaでは、パブリッシュサブスクリプションはトピックであり、ビジネスごと、アプリケーションごと、あるいはデータの種類ごとに専用に作成することができます。

Producer & Consumer

トピックにメッセージを発行するクライアント・アプリケーションはプロデューサーと呼ばれ、通常、継続的に1つまたは複数のトピックにメッセージを送信し、それらのトピック上のメッセージを購読するクライアント・アプリケーションはコンシューマーと呼ばれます。プロデューサーと同様に、コンシューマーも複数のトピックのメッセージを同時に購読することができます。プロデューサーとコンシューマーを総称して、クライアントと呼びます。Kafkaクラスタ内の複数のトピックに対して継続的にメッセージを生成および消費するプロデューサーとコンシューマーのインスタンスを同時に複数実行できます。

Broker

Kafkaのサーバーサイドは、Brokerと呼ばれるサービスプロセスで構成されています。つまり、Kafkaクラスタは複数のBrokerで構成され、クライアントから送られてきたリクエストを受信して処理したり、メッセージを永続化したりする役割を担っています。

同じマシン上で複数のBrokerプロセスを実行することもできますが、クラスタ内の1台のマシンがダウンしても、そのマシンで実行されているすべてのBrokerがハングアップしても、他のマシンのBrokerは外部へのサービスを提供できるように、異なるマシンで異なるBrokerを実行する方が一般的です。これもKafkaの高可用性を実現する手段の1つです！

Partitioning - Scalability

各パーティションは順序付けられた不変のレコード列です。パーティション内のレコードには、自己成長するID - オフセット

たとえレプリカメカニズムは、データの永続性やメッセージの非損失を保証するが、スケーラビリティの問題を解決するものではない。

レプリカを例にとると、現在ではリーダーレプリカとフォロワーレプリカがありますが、リーダーレプリカが大量のデータを蓄積して、1台のBrokerマシンでは収容しきれなくなったらどうしますか？データを複数のコピーに分割して、別々のBrokerに保存できないか？

このメカニズムがパーティショニングです。他の分散システムでは、スライシング、パーティショニングなどという言葉を聞いたことがあるかもしれません。

• MongoDBと Elasticsearch におけるシャーディング
• HBase地域

実は同じ原理で、パーティショニングが最も標準的な名称です！

Kafkaのパーティショニングメカニズムとは、各トピックを複数のパーティションに分割することです。プロデューサによって生成された各メッセージは、1つのパーティションにのみ送信されます。つまり、2重にパーティショニングされたトピックには、パーティション0かパーティション1のどちらかに1つのメッセージが送信されます。

先ほどのレプリカとパーティションの関係は？実は、レプリカはパーティションのレベルで定義されます。各パーティションには複数のレプリカを設定することができ、リーダーレプリカは1つ、フォロワーレプリカはN-1つだけです。プロデューサはパーティションにメッセージを書き込みます。パーティション内の各メッセージの位置に関する情報は、ディスプレースメントと呼ばれるデータによって特徴付けられます。あるプロデューサーが空のパーティションに10個のメッセージを書き込んだとします。

Topic

データトピックは、Kafkaでデータのストリームを表現するために使用される抽象化です。トピックは、データを公開する際にデータを分類するために使用したり、データを購読する際にトピックとして使用したりします。トピックは、複数のプロデューサーとコンシューマーを同時に持つことができます。

トピックはキューとして理解することができ、生産者と消費者はトピックに直面しています；

Replication -

高可用性を実現するもう一つの手段

kafka0.8では、パーティションの信頼性を確保するために、各パーティションのデータのバックアップを開始しました。

• 各パーティションは、冗長バックアップ戦略であるレプリケーションとして他のサーバーに複製されます。
• 同じブローカーで同じパーティションを複数複製することはできません。
• 各パーティションのレプリケーションでは、1つのリーダーと0つ以上のフォロワーが存在します。
  • リーダーは、このパーティションに対するすべての読み取りと書き込み要求を処理します。
  • フォロワーは受動的にデータを複製するだけです。
• リーダーが倒れると、フォロワーの中から新しいリーダーが選出されます。

レプリカの数は設定可能で、レプリカは同じデータを保持しますが、異なる

レプリカの分類

Kafkaは2種類のレプリカを定義しています。

• リーダーコピー 外部へのサービス提供、顧客プログラムとの交流
• フォロワーコピー 外界と交流することなく、リーダーコピーのみに受動的に従います。

他の多くのシステムではフォロワーレプリカは外部から利用可能で、例えばMySQLのスレーブは読み取り操作を処理できますが、Kafkaではフォロワーレプリカは外部から利用できません。

現在では、この主従関係を指すのにMaster-Slaveの使用を提唱していませんが、結局のところ、Slaveには奴隷という意味があり、人種差別を厳格に禁止している米国などでは、この表現は少し政治的に正しくないため、現在のシステムのほとんどはLeader-Followerに変更されています。

レプリカの仕組み

• プロデューサーは常にリーダーへメッセージを書きます。
• そして、消費者は常にリーダーからのメッセージを読みます。

フォロワーレプリカがすることはただ一つ、リーダーレプリカにリクエストを送り、リーダーが生成した最新のメッセージを送ってもらうことです。

Record

各レコードには、キー、値、タイムスタンプの3つの情報があります。

パーティションID＋オフセットがデータの場所を決めるもの パーティションが順番を決めるもの

Kafkaの3層メッセージングアーキテクチャ

• 最初のレイヤーはトピックレイヤーで、各トピックはM個のパーティションで構成され、さらにN個のレプリカで構成されます。
• 2つ目のレイヤーはパーティションレイヤーで、各パーティションのN個のレプリカのうち1個だけがリーダーとして機能し、外部にサービスを提供できます。他のN-1個のレプリカはフォロワーレプリカで、データの冗長性を提供するためだけに使われます。
• 第3層はメッセージ層で、パーティションには多数のメッセージが含まれ、各メッセージは0からインクリメンタルにシフトされます。

最後に、クライアントプログラムはパーティションのリーダーコピーとしかやり取りできません。

メッセージ階層について話した後は、Kafka Brokerがどのようにデータを永続化するかについて話しましょう。一言で言えば、Kafkaはメッセージログを使ってデータを保存します。ログとはディスク上の物理ファイルのことで、メッセージを書き込む際にのみ追記することができます。追記しかできないので、パフォーマンスの良いシーケンシャルI/O書き込みではなく、低速なランダムI/O操作を避けることができ、Kafkaの高いスループット特性を実現するための重要な手段となります。しかし、ログにメッセージを書き続けていると、いずれディスク容量が足りなくなるので、Kafkaは定期的にメッセージを削除してディスクを取り戻す必要があります。どうやって削除するの？単純にログのセグメンテーション機構を利用します。Kafkaの基礎では、ログとほぼ複数のログセグメントに細分化され、メッセージは、現在の最新のログセグメントに追加され、完全なログセグメントを書き込むと、Kafkaは自動的に新しいログセグメントを切り出し、古いログセグメントが封印されます。 バックグラウンドでKafkaは、また、定期的に古いログセグメントを削除することができますチェックされる時限タスクがあるように、ディスク領域を再利用する目的を達成するために。Kafkaはまた、定期的に古いセグメントを削除することができるかどうかをチェックするバックグラウンドで時限タスクを持っているディスク領域を取り戻すために。

ここでもまた、消費者に焦点が当てられています。ピアツーピアモデルとパブリッシュサブスクライブモデル。この文脈でのピアツーピアとは、同じメッセージを下流の1つのコンシューマだけが消費でき、他のコンシューマはそのメッセージを入手できないことを意味します。KafkaでこのP2Pモデルを実装する方法は、コンシューマーグループを導入することです。コンシューマーグループとは、複数のコンシューマーインスタンスが一緒になってグループを形成し、トピックのセットを消費することを意味します。このトピックセットの各パーティションは、グループ内の1つのコンシューマーインスタンスによってのみ消費され、他のコンシューマーインスタンスは消費できません。なぜコンシューマー・グループが導入されたのですか？主な理由は、コンシューマー側のスループットを向上させるためです。複数のコンシューマー・インスタンスが同時に消費することで、コンシューマー・サイド全体のスループットが加速します。コンシューマー・グループの仕組みについては、このコラムの後半で詳しく説明しますので、今はコンシューマー・グループが何をするのかだけ理解しておいてください。また、ここでのコンシューマー・インスタンスとは、コンシューマー・アプリケーションを実行しているプロセスであったり、スレッドであったりしますが、どちらもコンシューマー・インスタンスと呼びます。

コンシューマーグループ内のすべてのコンシューマーインスタンスは、サブスクライブされたトピックのデータを「共有」するだけでなく、さらにクールなことに、お互いを支援することもできます。グループ内のインスタンスに障害が発生した場合、Kafkaはそれを自動的に検出し、障害が発生したインスタンスが担当していたパーティションを別の生きているコンシューマーに転送することができます。このプロセスは、Kafkaで有名な「リバランシング」です。まあ、有名でもあり悪名高くもあるのですが、リバランシングによって引き起こされるコンシューマの問題はたくさんあるからです。実際、コミュニティが解決できないリバランシングのバグはたくさんあります。

各コンシューマがメッセージを消費するとき、そのコンシューマがパーティション のどこで現在消費しているかを記録するフィールドを持たなければなりません。このフィールドはコンシューマの変位です。上記の "変位 "は、パーティション内でのメッセージの位置を特徴づけるもので、これは一定です。一方、コンシューマの変位は、コンシューマの消費進捗の指標であるため、いつでも変化する可能性があります。さらに、各コンシューマはそれぞれ独自のコンシューマ変位を持っているので、この2種類の変位を区別することが重要です。個人的には、パーティション内のメッセージの変位をパーティション変位、消費者側の変位を消費者変位と呼んでいます。

まとめ

メッセージ：レコード。 Kafkaはメッセージエンジンであり、メッセージはKafkaの処理の主な対象です。Topic：トピック。トピックは、メッセージを運ぶための論理的なコンテナで、実際には特定のビジネスを区別するために使用されます。Partition（パーティション）： パーティション。各トピックは複数のパーティションを持つことができます。Message Offset (メッセージオフセット): パーティション内の各メッセージの位置。Replica: レプリカ。 Kafkaでは、データの冗長性を確保するために、同じメッセージを複数の場所にコピーすることができ、これらの場所をレプリカと呼びます。また、レプリカはリーダーレプリカとフォロワーレプリカに分類され、それぞれ役割が異なります。つまり、各パーティションに複数のレプリカを設定して、高可用性を実現することができます。Producer: プロデューサー。トピックに新しいメッセージを発行するアプリケーション。トピックからの新しいメッセージを購読するアプリケーション。Consumer Offset（コンシューマ・オフセット）: コンシューマの消費状況を特徴付けるもので、各コンシューマは独自のコンシューマ・オフセットを持ちます。Consumer Group（コンシューマー・グループ）: コンシューマー・グループ。 高スループットのために複数のパーティションを同時に消費する複数のコンシューマー・インスタンスのグループ。Rebalance：リバランス。コンシューマーグループ内のコンシューマーインスタンスがハングアップした後、他のコンシューマーインスタンスが自動的にトピックパーティションにサブスクライブするように再割り当てされるプロセス。

なぜKafkaは、MySQLのようにフォロワーコピーが外部にリードを提供できないのですか？

1、カフカのパーティションは、MySQLのマスタースレーブではなく、複数のブローカから読み取り、このように負荷分散を読み取るために作られている、圧力がメインにある：いくつかの理由のためにフォロワーから読み取らないでください2、カフカは、データとデータベースの性質がある実質的な違いは、データがストリーミングデータである消費の概念を持っているということです、カフカはメッセージキューですので、変位の必要性の消費は、データベースが物理的なデータは、この概念が存在しません。3は、プロデューサーは、カフカは、フォロワーがメッセージを確認するために待機するかどうかを制御するように構成することができます上記から読み取る場合、オフセット制御の消費者側は、より複雑です。上記から読んだ場合、全てのフォロワーが確認しないとプロデューサーに返信できないため、パフォーマンスが低下します。

まずはっきりさせておきたいのは、マスター・スレーブ分離に絶対的なメリットやデメリットはなく、単なるアーキテクチャ設計であり、それぞれに適用可能なシナリオがあるということです。次に、おっしゃる通り、RedisもMySQLもマスター・スレーブ読み書きの分離をサポートしていますが、個人的にはこれはシーンの使い方に関係していると思います。読み込みが多く、書き込みが比較的少ないタイプの負荷の場合、読み書き分離の利用は非常に良いソリューションです - フォロワーの水平展開をたくさん追加して、読み込み操作のパフォーマンスを向上させることができます。逆に、Kafkaは、その主なシナリオはまだデータストアではなく、メッセージエンジンで読み取りサービスを提供するために、通常、メッセージの頻繁な生産と消費を伴う、典型的な読み書きが少ないシナリオではないので、このシナリオでは読み書き分離スキームはあまり適していません。第三に、Kafkaのレプリカメカニズムは非同期のメッセージプルを使用するため、リーダーとフォロワーの間で不整合が発生します。読み書き分離を利用する場合、read-your-writesをどのように実現するか、monotonic readsをどのように確保するか、メッセージの因果関係の順序を逆にする問題に対処するかなど、レプリカの遅延がもたらす一貫性の問題に対処する必要があります。もちろん、最終的には、グローバルなメッセージの順序の反転の問題はまだKafkaに存在し、一般的な解決策は、単一のパーティションを使用することです。他の解決策は、Kafkaが現在提供していないバージョンベクタです。最後に、コミュニティは、特定の指定されたフォロワーコピーが外部の読み取りサービスを提供することを許可するような、適度な読み書き分離スキームの導入を検討しています。もちろん、この解決策はまだ議論中です

• Apache Kafka in Action.