メッセージブローカーを理解する。 ActiveMQ と Kafka を使用したメッセージングの仕組みを学習します。 第3章 カフカ

小さな本の翻訳の続き:
メッセージブローカーを理解する
著者：Jakub Korab、出版社：O'Reilly Media, Inc.、発行日：2017 年 9781492049296 月、ISBN：XNUMX。

以前に翻訳された部分: メッセージブローカーを理解する。 ActiveMQ と Kafka を使用したメッセージングの仕組みを学習します。 第1章;序章

CHAPTER 3

カフカ

Kafka は、従来のメッセージ ブローカーの制限の一部を回避し、さまざまなポイントツーポイント インタラクション用に複数のメッセージ ブローカーをセットアップする必要を避けるために LinkedIn によって開発されました。これについては、本書の 28 ページの「スケールアップとスケールアウト」で説明されています。ユースケース LinkedIn は、ページのクリックやアクセス ログなどの非常に大量のデータの一方向の取り込みに主に依存しながらも、プロデューサーや他の消費者の生産性に影響を与えることなく、そのデータを複数のシステムで使用できるようにしています。 実際、Kafka が存在する理由は、Universal Data Pipeline で説明されている種類のメッセージング アーキテクチャを取得するためです。

この最終目標を考えると、当然他の要件も生じます。 カフカは次のことを行う必要があります。

• 極めて速く行動する
• メッセージを処理するときにより多くの帯域幅を提供します
• パブリッシャー/サブスクライバーおよびポイントツーポイント モデルのサポート
• 消費者の追加を遅らせないでください。 たとえば、宛先のコンシューマの数が増えると、ActiveMQ のキューとトピックの両方のパフォーマンスが低下します。
• 水平方向にスケーラブルであること。 メッセージを保持する XNUMX つのブローカーが最大ディスク速度でのみメッセージを保持できる場合、パフォーマンスを向上させるために単一のブローカー インスタンスを超えてメッセージを保持することは理にかなっています。
• メッセージの保存と再取得へのアクセスを制限する

これらすべてを達成するために、Kafka はクライアントとメッセージング ブローカーの役割と責任を再定義するアーキテクチャを採用しました。 JMS モデルは非常にブローカー指向であり、ブローカーがメッセージの配布を担当し、クライアントはメッセージの送受信のみを気にする必要があります。 一方、Kafka はクライアント中心であり、クライアントは、非常に高速でスケーラブルなブローカーと引き換えに、消費者への関連メッセージの公平な配信など、従来のブローカーの機能の多くを引き受けます。 従来のメッセージング システムを使用してきた人にとって、Kafka を使用するには根本的な考え方の変更が必要です。
このエンジニアリングの方向性により、従来のブローカーと比較してスループットを何桁も向上できるメッセージング インフラストラクチャの作成が可能になりました。 後で説明するように、このアプローチにはトレードオフが伴います。つまり、Kafka は特定の種類のワークロードやインストールされているソフトウェアには適していません。

統合宛先モデル

上記の要件を満たすために、Kafka は、XNUMX 種類の宛先の下でパブリッシュ/サブスクライブとポイントツーポイント メッセージングを組み合わせました- トピック。 これは、メッセージング システムを使用したことがある人々にとっては混乱を招きます。「トピック」という言葉は、(トピックからの) 読み取りが永続的ではないブロードキャスト メカニズムを指します。 本書の序文で定義されているように、Kafka トピックはハイブリッド宛先タイプとみなされる必要があります。

この章の残りの部分では、特に明記しない限り、「トピック」という用語は Kafka トピックを指します。

トピックがどのように動作するか、またトピックがどのような保証を提供するかを完全に理解するには、まずトピックが Kafka でどのように実装されているかを確認する必要があります。
Kafka の各トピックには独自のログがあります。
Kafka にメッセージを送信するプロデューサーはこのログに書き込み、コンシューマーは常に前進するポインターを使用してログから読み取ります。 Kafka は、その部分のメッセージが読まれたかどうかに関係なく、ログの最も古い部分を定期的に削除します。 Kafka の設計の中心的な部分は、ブローカーはメッセージが読まれたかどうかを気にしないということです。それはクライアントの責任です。

「ログ」と「ポインタ」という用語は、 Kafka ドキュメント。 ここでは、理解を助けるためにこれらのよく知られた用語を使用しています。

このモデルは、すべてのキューからのメッセージが同じログに保存され、ブローカーがメッセージを読み取った後に削除済みとしてマークする ActiveMQ とはまったく異なります。
ここで、もう少し深く掘り下げて、トピック ログをさらに詳しく見てみましょう。
Kafka ログは複数のパーティションで構成されます (図3-1）。 Kafka は、各パーティションでの厳密な順序付けを保証します。 これは、特定の順序でパーティションに書き込まれたメッセージが同じ順序で読み取られることを意味します。 各パーティションは、次の内容を含むローリング ログ ファイルとして実装されます。 サブセット プロデューサーによってトピックに送信されたすべてのメッセージの（サブセット）。 作成されたトピックには、デフォルトで XNUMX つのパーティションが含まれています。 パーティションのアイデアは、水平スケーリングのための Kafka の中心的なアイデアです。

図 3-1。 Kafka パーティション

プロデューサが Kafka トピックにメッセージを送信するとき、メッセージをどのパーティションに送信するかを決定します。 これについては後ほど詳しく見ていきます。

メッセージを読む

メッセージを読みたいクライアントは、と呼ばれる名前付きポインタを管理します。 消費者団体を指します。 オフセット パーティション内のメッセージ。 オフセットは、パーティションの先頭の 0 から始まる増分位置です。 このコンシューマ グループは、API でユーザー定義の group_id を介して参照され、以下に対応します。 XNUMX つの論理コンシューマまたはシステム.

ほとんどのメッセージング システムは、複数のインスタンスとスレッドを使用して宛先からデータを読み取り、メッセージを並列処理します。 したがって、通常は、同じコンシューマ グループを共有する多くのコンシューマ インスタンスが存在します。

読解の問題は次のように表すことができます。

• トピックには複数のパーティションがあります
• コンシューマの複数のグループが同時にトピックを使用できる
• コンシューマのグループは複数の個別のインスタンスを持つことができます

これは、自明ではない多対多の問題です。 Kafka がコンシューマ グループ、コンシューマ インスタンス、パーティション間の関係をどのように処理するかを理解するために、徐々に複雑になる一連の読み取りシナリオを見てみましょう。

消費者および消費者団体

開始点として、XNUMX つのパーティション (図3-2).

図 3-2。 コンシューマがパーティションから読み取る

コンシューマ インスタンスが独自の group_id を使用してこのトピックに接続すると、読み取りパーティションとそのパーティション内のオフセットが割り当てられます。 このオフセットの位置は、最新の位置 (最新のメッセージ) または最も古い位置 (最も古いメッセージ) へのポインターとしてクライアントで構成されます。 コンシューマはトピックからメッセージをリクエスト (ポーリング) し、これによりメッセージがログから順番に読み取られます。
オフセット位置は定期的に Kafka にコミットされ、内部トピックにメッセージとして保存されます。 _consumer_offsets。 通常のブローカーとは異なり、読み取りメッセージは削除されず、クライアントはオフセットを巻き戻して、すでに表示されたメッセージを再処理できます。

XNUMX 番目の論理コンシューマが別の group_id を使用して接続すると、最初のポインタから独立した XNUMX 番目のポインタを管理します (図3-3）。 したがって、Kafka トピックは、XNUMX つのコンシューマーが存在するキューのように機能し、複数のコンシューマーがサブスクライブする通常のパブリッシュ/サブスクライブ (pub-sub) トピックのように機能します。さらに、すべてのメッセージが保存され、複数回処理できるという利点もあります。

図3-3。 異なるコンシューマ グループ内の XNUMX つのコンシューマが同じパーティションから読み取る

消費者グループの消費者

XNUMX つのコンシューマ インスタンスがパーティションからデータを読み取るとき、ポインタを完全に制御し、前のセクションで説明したようにメッセージを処理します。
コンシューマーの複数のインスタンスが同じ group_id で XNUMX つのパーティションを持つトピックに接続されている場合、最後に接続したインスタンスにポインターの制御が与えられ、その瞬間からすべてのメッセージを受信します (図3-4).

図3-4。 同じコンシューマ グループ内の XNUMX つのコンシューマが同じパーティションから読み取る

コンシューマ インスタンスの数がパーティションの数を超えるこの処理モードは、一種の排他的コンシューマと考えることができます。 これは、コンシューマ インスタンスの「アクティブ-パッシブ」(または「ホット-ウォーム」) クラスタリングが必要な場合に役立ちますが、複数のコンシューマを並行して実行する (「アクティブ-アクティブ」または「ホット-ホット」) ことの方がはるかに一般的です。消費者はスタンバイ状態です。

上で説明したこのメッセージ配布動作は、通常の JMS キューの動作と比較すると驚くべきものになる可能性があります。 このモデルでは、キューに送信されたメッセージは XNUMX つのコンシューマー間で均等に分散されます。

ほとんどの場合、コンシューマーの複数のインスタンスを作成するときは、メッセージを並行して処理するか、読み取り速度を向上させるか、読み取りプロセスの安定性を高めるためにこれを行います。 パーティションからデータを読み取ることができるのは一度に XNUMX つのコンシューマー インスタンスだけですが、Kafka ではこれをどのように実現するのでしょうか?

これを行う XNUMX つの方法は、単一のコンシューマー インスタンスを使用してすべてのメッセージを読み取り、スレッド プールに渡すことです。 このアプローチは処理スループットを向上させますが、コンシューマ ロジックの複雑性は増大し、読み取りシステムの堅牢性を向上させることはできません。 停電または同様のイベントによりコンシューマの XNUMX つのコピーがダウンした場合、減算は停止します。

Kafka でこの問題を解決する標準的な方法は、 b を使用することです。Оより多くのパーティション。

パーティショニング

パーティションは、単一のブローカー インスタンスの帯域幅を超えてトピックの読み取りとスケーリングを並列化するための主要なメカニズムです。 これをよりよく理解するために、XNUMX つのパーティションを持つトピックがあり、XNUMX 人のコンシューマーがこのトピックをサブスクライブする状況を考えてみましょう (図3-5).

図3-5。 XNUMX 人のコンシューマーが複数のパーティションから読み取ります

このシナリオでは、コンシューマーは両方のパーティションの group_id に対応するポインターに対する制御を与えられ、両方のパーティションからメッセージの読み取りを開始します。
同じ group_id の追加のコンシューマーがこのトピックに追加されると、Kafka はパーティションの XNUMX つを最初のコンシューマーから XNUMX 番目のコンシューマーに再割り当てします。 その後、コンシューマの各インスタンスはトピックの XNUMX つのパーティションから読み取ります (図3-6).

メッセージが 20 スレッドで並列処理されるようにするには、少なくとも 20 のパーティションが必要です。 パーティションの数が少ない場合は、排他的コンシューマの説明で前述したように、何も処理する必要のないコンシューマが残されます。

図3-6。 同じコンシューマ グループ内の XNUMX つのコンシューマが異なるパーティションから読み取ります

このスキームにより、JMS キューを維持するために必要なメッセージ配布と比較して、Kafka ブローカーの複雑さが大幅に軽減されます。 ここでは、次の点を心配する必要はありません。

• ラウンドロビン割り当て、プリフェッチ バッファの現在の容量、または前のメッセージ (JMS メッセージ グループの場合) に基づいて、どのコンシューマが次のメッセージを受信する必要があるか。
• どのメッセージがどのコンシューマに送信されるか、また失敗した場合にはメッセージを再配信する必要があるかどうか。

Kafka ブローカーが行う必要があるのは、コンシューマがメッセージを要求したときに、コンシューマにメッセージを順番に渡すことだけです。

ただし、校正と失敗したメッセージの再送信を並列化する要件はなくなりません。それらの責任は単にブローカーからクライアントに移されるだけです。 これは、コード内でそれらを考慮する必要があることを意味します。

メッセージの送信

どのパーティションにメッセージを送信するかを決定するのは、そのメッセージの作成者の責任です。 これが行われるメカニズムを理解するには、まず実際に何を送信しているのかを考える必要があります。

JMS ではメタデータ (ヘッダーとプロパティ) とペイロード (ペイロード) を含む本文を含むメッセージ構造を使用しますが、Kafka ではメッセージは次のようになります。 「キーと値」のペア。 メッセージ ペイロードは値として送信されます。 一方、キーは主にパーティション化に使用され、次のものが含まれている必要があります。 ビジネスロジック固有のキー関連するメッセージを同じパーティションに配置します。

第 2 章では、関連イベントを XNUMX 人の消費者が順番に処理する必要があるオンライン ベッティング シナリオについて説明しました。

1. ユーザーアカウントが設定されました。
2. お金がアカウントに入金されます。
3. アカウントからお金を引き出す賭けが行われます。

各イベントがトピックに投稿されたメッセージである場合、自然キーはアカウント ID になります。
Kafka プロデューサー API を使用してメッセージが送信されると、そのメッセージはパーティション関数に渡され、メッセージと Kafka クラスターの現在の状態に応じて、メッセージの送信先となるパーティションの ID が返されます。 この機能は、Partitioner インターフェイスを介して Java に実装されます。

このインターフェースは次のようになります。

interface Partitioner {
    int partition(String topic,
        Object key, byte[] keyBytes, Object value, byte[] valueBytes, Cluster cluster);
}

パーティショナーの実装では、キーに対してデフォルトの汎用ハッシュ アルゴリズムを使用してパーティションを決定するか、キーが指定されていない場合はラウンドロビンを使用します。 ほとんどの場合、このデフォルト値が適切に機能します。 ただし、将来的には、独自のコードを作成することになるでしょう。

独自のパーティショニング戦略を作成する

メッセージ ペイロードとともにメタデータを送信する例を見てみましょう。 この例のペイロードは、ゲーム アカウントに入金するための命令です。 命令は、送信時に変更されないことを保証したいものであり、信頼できる上流システムのみがその命令を開始できることを確認したいものです。 この場合、送信システムと受信システムは、メッセージを認証するために署名を使用することに同意します。
通常の JMS では、単に「メッセージ署名」プロパティを定義し、それをメッセージに追加します。 ただし、Kafka はメタデータを渡すためのメカニズムを提供せず、キーと値のみを提供します。

値は整合性を保持したい銀行振込ペイロードであるため、キーで使用するデータ構造を定義する以外に選択肢はありません。 アカウントに関連するすべてのメッセージを順番に処理する必要があるため、パーティショニングにアカウント ID が必要であると仮定すると、次の JSON 構造が考えられます。

{
  "signature": "541661622185851c248b41bf0cea7ad0",
  "accountId": "10007865234"
}

署名の値はペイロードに応じて変化するため、パーティショナー インターフェイスのデフォルトのハッシュ戦略では関連メッセージを確実にグループ化できません。 したがって、このキーを解析し、accountId 値を分割する独自の戦略を作成する必要があります。

Kafka には、ストア内のメッセージの破損を検出するためのチェックサムが含まれており、セキュリティ機能の完全なセットが備わっています。 それでも、上記のような業界固有の要件が発生することがあります。

ユーザーのパーティション化戦略では、関連するすべてのメッセージが同じパーティションに収まるようにする必要があります。 これは単純そうに見えますが、関連するメッセージの順序付けの重要性とトピック内のパーティション数がどのように固定されているかにより、要件が複雑になる場合があります。

トピック内のパーティションの数は、トラフィックが当初の予想を超えた場合に追加される可能性があるため、時間の経過とともに変化する可能性があります。 したがって、メッセージ キーは、最初に送信されたパーティションに関連付けることができ、プロデューサー インスタンス間で共有される状態の一部を意味します。

考慮すべきもう XNUMX つの要素は、パーティション間でのメッセージの均等な分散です。 通常、キーはメッセージ全体に均等に分散されず、ハッシュ関数は少数のキーのセットに対してメッセージが公平に分散されることを保証しません。
どのようなメッセージの分割を選択しても、区切り文字自体を再利用する必要がある場合があることに注意することが重要です。

地理的に異なる場所にある Kafka クラスター間でデータをレプリケートする要件を考慮してください。 この目的のために、Kafka には MirrorMaker と呼ばれるコマンド ライン ツールが付属しています。これは、あるクラスターからメッセージを読み取り、別のクラスターに転送するために使用されます。

MirrorMaker は、クラスター間でレプリケートするときにメッセージ間の相対的な順序を維持するために、レプリケートされたトピックのキーを理解する必要があります。これは、そのトピックのパーティションの数が XNUMX つのクラスターで同じではない可能性があるためです。

デフォルトのハッシュまたはラウンド ロビンがほとんどのシナリオで適切に機能するため、カスタム パーティショニング戦略は比較的まれです。 ただし、強力な順序付けの保証が必要な場合、またはペイロードからメタデータを抽出する必要がある場合は、パーティショニングを詳しく検討する必要があります。

Kafka のスケーラビリティとパフォーマンスの利点は、従来のブローカーの責任の一部をクライアントに移すことによってもたらされます。 この場合、並行して動作する複数のコンシューマ間で潜在的に関連するメッセージを配布する決定が行われます。

JMS ブローカーもそのような要件に対処する必要があります。 興味深いことに、JMS メッセージ グループ (スティッキー ロード バランシング (SLB) 戦略のバリエーション) を通じて実装された、関連するメッセージを同じコンシューマに送信するメカニズムでも、送信者がメッセージを関連するものとしてマークする必要があります。 JMS の場合、ブローカーは、この関連メッセージのグループを多数のコンシューマーの中から XNUMX つのコンシューマーに送信し、コンシューマーが落ちた場合にはグループの所有権を譲渡する責任があります。

プロデューサー契約

メッセージを送信するときに考慮すべきことはパーティショニングだけではありません。 Java API のプロデューサー クラスの send() メソッドを見てみましょう。

Future < RecordMetadata > send(ProducerRecord < K, V > record);
Future < RecordMetadata > send(ProducerRecord < K, V > record, Callback callback);

どちらのメソッドも Future を返すことに注意してください。これは、送信操作がすぐに実行されないことを示します。 その結果、メッセージ (ProducerRecord) が各アクティブ パーティションの送信バッファに書き込まれ、Kafka クライアント ライブラリのバックグラウンド スレッドとしてブローカーに送信されます。 これにより処理が驚くほど高速になりますが、経験の浅いアプリケーションではプロセスが停止するとメッセージが失われる可能性があります。

いつものように、パフォーマンスを犠牲にして送信操作の信頼性を高める方法があります。 このバッファのサイズは 0 に設定でき、次のように、送信アプリケーション スレッドはブローカへのメッセージ転送が完了するまで待機するようになります。

RecordMetadata metadata = producer.send(record).get();

メッセージの読み取りに関する詳細

メッセージの読み取りには、さらに複雑な点があるため、推測する必要があります。 メッセージに応答してメッセージ リスナーを実行できる JMS API とは異なり、 消費財 Kafka はポーリングのみを行います。 方法を詳しく見てみましょう ポーリング()この目的のために使用されます:

ConsumerRecords < K, V > poll(long timeout);

メソッドの戻り値は、複数のオブジェクトを含むコンテナ構造です。 消費者記録 場合によっては複数のパーティションから。 消費者記録 それ自体は、派生元のパーティションなど、関連するメタデータを含むキーと値のペアのホルダー オブジェクトです。

第 2 章で説明したように、クライアントがメッセージを処理できない場合やメッセージが中止された場合など、メッセージの処理が成功または失敗した後にどうなるかに留意する必要があります。 JMS では、これは確認応答モードを通じて処理されました。 ブローカーは、正常に処理されたメッセージを削除するか、生のメッセージまたは偽のメッセージを再配信します (トランザクションが使用されたと仮定します)。
Kafka の動作は大きく異なります。 メッセージは校正後にブローカーで削除されません。失敗した場合に何が起こるかは校正コード自体の責任です。

すでに述べたように、コンシューマ グループはログ内のオフセットに関連付けられています。 このオフセットに関連付けられたログ位置は、次のメッセージに応答して発行されるメッセージに対応します。 ポーリング()。 このオフセットが増加する時点が読み取りの決定的になります。

前に説明した読み取りモデルに戻ると、メッセージ処理は XNUMX つの段階で構成されます。

1. 読むメッセージを取得します。
2. メッセージを処理します。
3. メッセージを確認します。

Kafka コンシューマーには構成オプションが付属しています 自動コミットを有効にする。 これは、「自動」という単語を含む設定と同様に、頻繁に使用されるデフォルト設定です。

Kafka 0.10 より前では、このオプションを使用するクライアントは、次の呼び出しで読み取られた最後のメッセージのオフセットを送信していました。 ポーリング() 加工後。 これは、クライアントがすでにフェッチしたメッセージを処理していても、呼び出す前に予期せず破棄された場合、それらのメッセージを再処理できることを意味します。 ポーリング()。 ブローカーはメッセージが読み取られた回数に関する状態を保持しないため、次にそのメッセージを取得するコンシューマーは、何か悪いことが起こったことを知りません。 この動作は疑似トランザクションでした。 オフセットはメッセージが正常に処理された場合にのみコミットされますが、クライアントが中止された場合、ブローカーは同じメッセージを別のクライアントに再度送信します。 この動作はメッセージ配信の保証と一致していました。少なくとも一度は"

Kafka 0.10 では、設定に従ってクライアント ライブラリによってコミットが定期的にトリガーされるようにクライアント コードが変更されました。 auto.commit.interval.ms。 この動作は、JMS AUTO_ACKNOWLEDGE モードと DUPS_OK_ACKNOWLEDGE モードの間のどこかにあります。 自動コミットを使用すると、メッセージが実際に処理されたかどうかに関係なく、メッセージがコミットされる可能性があります。これは、遅いコンシューマーの場合に発生する可能性があります。 コンシューマが中止された場合、メッセージは次のコンシューマによってコミットされた位置からフェッチされるため、メッセージが失われる可能性があります。 この場合、Kafka はメッセージを失ったのではなく、読み取りコードがメッセージを処理しなかっただけです。

このモードにはバージョン 0.9 と同じ約束があります。つまり、メッセージは処理できますが、失敗するとオフセットがコミットされず、配信が XNUMX 倍になる可能性があります。 実行時に取得するメッセージが増えるほど ポーリング()、この問題はさらに大きくなります。

21 ページの「キューからのメッセージの読み取り」で説明したように、障害モードを考慮すると、メッセージング システムではメッセージを XNUMX 回だけ配信することはできません。

Kafka では、オフセット (offset) をコミット (コミット) する方法は、自動と手動の 0.9 つがあります。 どちらの場合も、メッセージが処理されたもののコミット前に失敗した場合、メッセージは複数回処理される可能性があります。 コミットがバックグラウンドで発生し、コードが処理される前に完了してしまった場合 (おそらく Kafka XNUMX 以前の場合)、メッセージをまったく処理しないことも選択できます。

パラメータを設定することで、Kafka コンシューマ API で手動オフセット コミット プロセスを制御できます。 自動コミットを有効にする false に設定し、次のメソッドのいずれかを明示的に呼び出します。

void commitSync();
void commitAsync();

メッセージを「少なくとも XNUMX 回」処理したい場合は、オフセットを手動でコミットする必要があります。 commitSync()メッセージを処理した直後にこのコマンドを実行します。

これらのメソッドでは、メッセージが処理される前に確認応答することはできませんが、トランザクションであるかのように見せながら潜在的な処理遅延を排除することはできません。 Kafka にはトランザクションはありません。 クライアントには次のことを行う機能がありません。

• 偽のメッセージを自動的にロールバックします。 メッセージの再配信をブローカーに依存できないため、コンシューマー自身が、問題のあるペイロードやバックエンドの停止によって生じる例外を処理する必要があります。
• 98 つのアトミック操作で複数のトピックにメッセージを送信します。 すぐに説明するように、さまざまなトピックやパーティションに対する制御は、送信時にトランザクションを調整しない Kafka クラスター内のさまざまなマシンに常駐することができます。 この記事の執筆時点では、KIP-XNUMX でこれを可能にするためにいくつかの作業が行われています。
• あるトピックからの XNUMX つのメッセージの読み取りを、別のトピックへの別のメッセージの送信と関連付けます。 繰り返しになりますが、Kafka のアーキテクチャは XNUMX つのバスとして実行される多くの独立したマシンに依存しており、これを隠蔽する試みは行われていません。 たとえば、リンクを可能にする API コンポーネントはありません。 消費者 и プロデューサー トランザクション中。 JMS では、これはオブジェクトによって提供されます。 セッションを開くそこから作成される メッセージプロデューサー и メッセージ消費者.

トランザクションに依存できない場合、従来のメッセージング システムが提供するセマンティクスに近いセマンティクスを提供するにはどうすればよいでしょうか?

コンシューマのクラッシュ時など、メッセージが処理される前にコンシューマのオフセットが増加する可能性がある場合、コンシューマには、パーティションが割り当てられているときにコンシューマ グループがメッセージを見逃したかどうかを知る方法がありません。 したがって、XNUMX つの戦略は、オフセットを前の位置に巻き戻すことです。 Kafka コンシューマー API は、このために次のメソッドを提供します。

void seek(TopicPartition partition, long offset);
void seekToBeginning(Collection < TopicPartition > partitions);

方法 求める（） メソッドで使用できます
offsetsForTimes(地図検索するタイムスタンプ) 過去のある特定の時点の状態に巻き戻すこと。

このアプローチを使用すると、暗黙的に、以前に処理された一部のメッセージが再度読み取られて処理される可能性が非常に高くなります。 これを回避するには、第 4 章で説明したように、冪等読み取りを使用して、以前に表示したメッセージを追跡し、重複を排除します。

あるいは、メッセージの損失や重複が許容される限り、コンシューマー コードを単純にすることもできます。 ログイベント、メトリクス、クリック追跡などの処理など、Kafka が一般的に使用されるユースケースを見ると、個々のメッセージの損失が周囲のアプリケーションに大きな影響を与える可能性は低いことがわかります。 このような場合は、デフォルト値をそのまま使用できます。 一方、アプリケーションで支払いを送信する必要がある場合は、個々のメッセージを注意深く処理する必要があります。 すべてはコンテキストに依存します。

個人的な観察によると、メッセージの強度が増すにつれて、個々のメッセージの価値は減少します。 大きなメッセージは、集約された形式で表示すると価値がある傾向があります。

高可用性

高可用性に対する Kafka のアプローチは、ActiveMQ のアプローチとは大きく異なります。 Kafka は、すべてのブローカー インスタンスが同時にメッセージを受信および配布するスケールアウト クラスターを中心に設計されています。

Kafka クラスターは、異なるサーバー上で実行される複数のブローカー インスタンスで構成されます。 Kafka は、各ノードが独自の専用ストレージを持つ通常のスタンドアロン ハードウェア上で実行されるように設計されています。 複数の計算ノードが時間を競う可能性があるため、ネットワーク接続ストレージ (SAN) の使用は推奨されません。Ы保管間隔が長くなり、競合が発生します。

カフカは 常にオン システム。 多くの大規模な Kafka ユーザーはクラスターをシャットダウンすることはなく、ソフトウェアは常に順次再起動して更新されます。 これは、メッセージおよびブローカー間の対話について、以前のバージョンとの互換性を保証することによって実現されます。

サーバークラスターに接続されたブローカー 飼育係、構成データ レジストリとして機能し、各ブローカーの役割を調整するために使用されます。 ZooKeeper 自体は分散システムであり、次のような情報の複製を通じて高可用性を提供します。 定足数.

基本的なケースでは、次のプロパティを持つトピックが Kafka クラスター内に作成されます。

• パーティションの数。 前に説明したように、ここで使用される正確な値は、並列読み取りの必要なレベルによって異なります。
• レプリケーション係数 (係数) は、クラスター内のブローカー インスタンスの数がこのパーティションのログを含む必要があるかを決定します。

ZooKeeper を調整に使用して、Kafka はクラスター内のブローカー間で新しいパーティションを公平に分散しようとします。 これは、コントローラーとして機能する単一のインスタンスによって実行されます。

実行時 トピックパーティションごとに コントローラー ブローカーに役割を割り当てる リーダー (リーダー、マスター、プレゼンター) フォロワー （従者、奴隷、部下）。 このパーティションのリーダーとして機能するブローカーは、プロデューサから送信されたすべてのメッセージを受信し、そのメッセージをコンシューマに配布する責任があります。 メッセージがトピック パーティションに送信されると、そのパーティションのフォロワーとして機能するすべてのブローカー ノードにメッセージが複製されます。 パーティションのログを含む各ノードは次のように呼ばれます。 レプリカ。 ブローカーは、一部のパーティションではリーダーとして機能し、他のパーティションではフォロワーとして機能します。

リーダーが保持するすべてのメッセージを含むフォロワーが呼び出されます。 同期されたレプリカ (同期状態にあるレプリカ、同期レプリカ)。 パーティションのリーダーとして機能するブローカーがダウンした場合、そのパーティションに対して最新の状態または同期されているブローカーがリーダーの役割を引き継ぐことができます。 信じられないほど持続可能なデザインです。

プロデューサー設定の一部はパラメータです。 ACKこれにより、アプリケーション スレッドが送信を続行する前にメッセージの受信を確認 (承認) する必要があるレプリカの数が決まります (0、1、またはすべて)。 に設定されている場合 をメッセージを受信すると、リーダーは、トピック設定で定義された複数のキュー (それ自体を含む) からレコードの確認 (肯定応答) を受信するとすぐに、プロデューサーに確認を送り返します。 min.insync.レプリカ (デフォルトは 1)。 メッセージを正常に複製できない場合、プロデューサはアプリケーション例外をスローします (レプリカが足りない または 追加後のレプリカが不足しています).

一般的な構成では、レプリケーション係数 3 (パーティションごとに 1 つのリーダー、2 つのフォロワー) とパラメーターを使用してトピックが作成されます。 min.insync.レプリカ この場合、クラスターは、クライアント アプリケーションに影響を与えることなく、トピック パーティションを管理しているブローカーの 2 つがダウンすることを許可します。

これは、パフォーマンスと信頼性の間のすでにおなじみのトレードオフに戻ります。 レプリケーションは、フォロワーからの確認 (確認応答) を待機する追加の時間を犠牲にして発生します。 ただし、並列実行されるため、少なくとも XNUMX つのノードへのレプリケーションは XNUMX つのノードと同じパフォーマンスになります (ネットワーク帯域幅の使用量の増加を無視します)。

このレプリケーション スキームを使用することにより、Kafka は、次の操作で各メッセージを物理的にディスクに書き込む必要性を巧みに回避します。 同期()。 プロデューサによって送信された各メッセージはパーティション ログに書き込まれますが、第 2 章で説明したように、ファイルへの書き込みは最初はオペレーティング システムのバッファ内で行われます。 このメッセージが別の Kafka インスタンスにレプリケートされ、そのメモリ内にある場合、リーダーの喪失はメッセージ自体が失われたことを意味するものではなく、同期されたレプリカによって引き継がれる可能性があります。
手術の拒否 同期() つまり、Kafka はメッセージをメモリに書き込むのと同じ速さでメッセージを受信できます。 逆に、メモリをディスクにフラッシュすることを避けることができる時間が長ければ長いほど、より良いことになります。 このため、Kafka ブローカーに 64 GB 以上のメモリが割り当てられることも珍しくありません。 このメモリ使用量は、単一の Kafka インスタンスが従来のメッセージ ブローカーの数千倍の速度で簡単に実行できることを意味します。

Kafka は操作を適用するように構成することもできます 同期() メッセージパッケージに。 Kafka のすべてはパッケージ指向であるため、実際には多くのユースケースで非常にうまく機能し、非常に強力な保証を必要とするユーザーにとって便利なツールです。 Kafka の純粋なパフォーマンスの多くは、パケットとしてブローカーに送信されるメッセージから得られ、これらのメッセージは、次のコマンドを使用して連続ブロックでブローカーから読み取られます。 ゼロコピー 操作 (あるメモリ領域から別のメモリ領域にデータをコピーするタスクが実行されない操作)。 後者はパフォーマンスとリソースを大幅に向上させますが、これはパーティション スキームを定義する基礎となるログ データ構造を使用することによってのみ可能になります。

トピック パーティションは多くの個別のマシンにスケールアウトできるため、Kafka クラスターでは単一の Kafka ブローカーを使用するよりもはるかに優れたパフォーマンスが可能です。

結果

この章では、Kafka アーキテクチャがクライアントとブローカー間の関係をどのように再考して、従来のメッセージ ブローカーの何倍ものスループットを備えた非常に堅牢なメッセージング パイプラインを提供する方法について説明しました。 これを実現するために使用される機能について説明し、この機能を提供するアプリケーションのアーキテクチャについて簡単に説明しました。 次の章では、メッセージング ベースのアプリケーションが解決する必要がある一般的な問題を見て、それらに対処する戦略について説明します。 この章の最後では、メッセージング テクノロジ一般について説明する方法を概説して、ユース ケースに対するメッセージング テクノロジの適合性を評価できるようにします。

以前に翻訳された部分: メッセージブローカーを理解する。 ActiveMQ と Kafka を使用したメッセージングの仕組みを学習します。 第1章

翻訳完了: tele.gg/middle_java

継続するには...

登録ユーザーのみがアンケートに参加できます。 ログインお願いします。

あなたの組織では Kafka が使用されていますか?

• はい

• ノー

• 以前は使用されていましたが、現在は使用されていません

• 使用する予定です

38 人のユーザーが投票しました。 8名のユーザーが棄権した。

出所： habr.com