Kafkaシリーズの深い理解（5）-Kafkaの信頼できるデータ送信
シリーズ記事ディレクトリ
序文
このシリーズは、「カフカの決定的なガイド」という本を読んだ後の私の筆記録と考えです。
テキスト
この記事は主にカフカの信頼できる送信について説明します
信頼性の保証と複製
データベースにはデータベースの信頼性があります。たとえば、MysqlのACIDはトランザクション特性を保証します。次に、Kafkaにも対応する保証があります。次の側面から確実に：
- Kafkaは、パーティション化されたメッセージの順序を保証します。メッセージBがメッセージAの後に書き込まれる場合、KafkaはメッセージBのオフセットがAのオフセットよりも大きいことを確認し、コンシューマーは最初にメッセージAを読み取り、次にBを読み取ります。
- メッセージがパーティションの同期されたすべてのコピー（必ずしもディスクに書き込まれる必要はありません）に書き込まれる場合にのみ、「コミット済み」と見なされます。プロデューサーは別の確認メカニズム、acksを選択します。
- 1つのコピーがアクティブである限り、送信されたメッセージは失われません。
- 消費者は、送信されたメッセージのみを読むことができます。
- すべてのリクエストはプライマリコピーからのみ流入および流出でき、コピーからのリクエストはデータバックアップとしてのみ機能します。
上記の基本的な保証メカニズムは信頼性の高いシステムを構築するために使用できますが、それだけでは完全な信頼性を保証することはできません。次に、Kafkaのレプリケーションメカニズムと重要な構成パラメーターに基づいたKafkaの信頼性について説明します。
Kafkaのレプリケーションメカニズムとパーティション化されたマルチコピーアーキテクチャは、Kafkaの信頼性保証の中核です。ここに簡単なレビューがあります。
- Kafkaトピックは複数のパーティションに分割され、パーティションは基本的なデータブロックです。
- Kafkaは、パーティション内のメッセージが正しいことを保証します。
- 各パーティションは複数のコピーを持つことができ、そのうちの1つのコピーのみがマスターコピーで、他のコピーはスレーブコピーです。
- マスターコピーは要求の処理を担当し、スレーブコピーはマスターコピーとのペースを維持することのみを担当します。リーダーコピーが使用できない場合、スレーブコピーはそれを置き換えることを選択します。
- パーティションリーダーは同期コピーであり、次の3つの条件を満たす必要があります。
1.zookeeperとのアクティブなセッションがあります。
2.過去10代のリーダーから情報を入手した。
3.過去10代で得られた情報は最新のものです。
信頼できるシステムのブローカー
Kafkaメッセージストレージの信頼性に影響を与えるブローカーには、さらに3つの重要なパラメーターがあります。ここでは、これら3つのパラメーターの構成から説明します。
複製係数
テーマレベルの構成パラメーター：replication.factor
ブローカーレベル：default.replication.factor
Kafkaのデフォルトのレプリケーション係数は3です。これは、各パーティションが3つの異なるブローカーによって3回レプリケートされることを意味します。レプリケーションファクターがNの場合、N-1ブローカーに障害が発生した場合でも、トピックからデータを読み書きできるため、レプリケーションファクターが高いほど、可用性と信頼性が向上します。ただし、欠点もあります。レプリケーション係数がNの場合、少なくともN個のブローカーとN個のデータコピーが必要であり、ディスク容量のN倍を占めます。Nが大きいほど、オーバーヘッドが大きくなります。
ブローカーの再始動のためにトピックが使用不可であることが許容できる場合、複製係数は1です。
レプリケーションファクターが2の場合、1つのブローカー障害を許容できることを意味しますが、レプリケーションファクターが2の場合、再起動の問題によりクラスターが使用できない可能性があります。
したがって、通常は複製係数3で十分です。
リーダー選出
パラメーター：unclean.leader.electionはブローカーレベルで構成されます。デフォルトはtrueです。つまり、パーティションリーダーが使用できない場合、同期されたコピーが新しいリーダーとして選択されます。選出プロセス中にデータが失われない場合、つまり、送信されたデータはすべての同期されたコピーに同時に存在します。時間、それから選挙は完了として呼ばれます。このパラメーターがtrueの場合、同期されていないコピーがリーダーになること、つまり不完全な選択が許可されます。
非同期レプリカを新しいリーダーに昇格できない場合、古いリーダーが応答するまでパーティションは使用できず、クラスターは長期間使用できない可能性があります。信頼性が低下しています。
同期されていないコピーを新しいリーダーに昇格できる場合、このコピーが非同期になった後に古いリーダーに書き込まれたすべてのメッセージが失われ、データの不整合が発生します。
つまり、システムに高可用性に対する高い要件があり、ある程度のデータの不整合を受け入れることができる場合は、このパラメーターをtrueに設定してください。それ以外の場合、銀行など、高いデータ整合性を必要とする一部のシステムでは、このパラメーターはfalseに設定されます。
同期が最も少ないコピー
パラメーター（サブジェクトとブローカーレベルは名前です）：min.insync.replicas
まず、Kafkaの信頼性保証の定義について説明します。メッセージは、同期されたすべてのレプリカに書き込まれた後にのみコミットされたと見なされます。また、このパラメーターは、同期されたレプリカの最小数を指定します。
1.値が1に設定されている場合、同期されたコピーがある限り、メッセージは送信されたと見なされますが、同期されたコピーのみがダウンしている場合、機能は停止します。
2.同期されたレプリカの数が構成で指定された数より少ない場合、メッセージを送信しようとしているプロデューサーはNotEnoughReplicasExceptionを受け取ります。
3.もちろん、コンシューマーは既存のデータを読み取ることができます。これが発生した場合、ブローカーの再起動など、使用できないパーティションを復元し、同期されるのを待つ必要があります。
明らかに、上記の3つのパラメータは、Kafkaの信頼性の高い伝送に大きな影響を与えます。ただし、信頼性を向上させるには、ブローカーレベルで構成するだけでは不十分です。また、プロデューサーとコンシューマーの両方から確実に構成する必要があります。
信頼できるシステムのプロデューサー
まず、プロデューサーの送信モードについて詳しく説明します。
- acks = 0
これは、プロデューサーがネットワークを介してメッセージを送信できる場合、メッセージがKafkaに正常に書き込まれたと見なされることを意味します。
問題は、このモードでは、エラーの可能性が非常に高いことです。これは、Javaのオブジェクトなどのメッセージを送信すると、送信プロセスで、シーケンスが変換に失敗した場合、またはネットワークカードが故障した場合、それは送信が失敗したことを意味しますか？
一般に、acks = 0モードはベンチマークに使用されます。これは、このモードでは、高スループットとブロードバンド使用率、つまり速度が精度を犠牲にするためです。
- acks = 1
これは、リーダーがメッセージを受信してパーティションデータファイルに書き込むと、確認応答またはエラー応答を返すことを意味します。このモードは、acks = 0のメッセージよりも信頼性があります。このモードでは、通常のリーダーの選出が発生した場合（つまり、元のリーダーが崩壊し、残りの同期されたフォロワーのコピーが新しいリーダーのコピーの選出を開始した場合）、プロデューサーは選挙中に関連する例外を受け取り、プロデューサーが正しくできる場合このエラーを処理すると、彼はメッセージの送信を再試行します。、最終ニュースは新しいリーダーに届きます。
ただし、このモードでもデータが失われる可能性があります。たとえば、メッセージはリーダーに正常に書き込まれましたが、メッセージがフォロワーコピーにコピーされる前にリーダーがクラッシュします。
- acks = all
これは、リーダーが同期されたすべてのレプリカがメッセージを受信するのを待ってから、確認またはエラー応答を返すことを意味します。もちろん、acks = allの場合は、構成min.insync.replicasと組み合わせて、確認を返す前に少なくともメッセージを受信できるレプリカの数を決定できるようにすることをお勧めします。
利点：これが最も安全なアプローチです。
短所：スループットが最も遅くなります。
次に、プロデューサーの再試行パラメーターの観点から：
一般的に、ブローカーがエラーを送信した場合、返されたエラーは再試行することで解決できます。プロデューサーが処理する必要のあるエラーは2つの部分で構成されます。
- プロデューサーが自動的に処理できるエラー：LEADER_NOT_AVAILABLE（ブローカーから返される）
- 開発者が手動で処理する必要のあるエラー（プロデューサーは自動的に処理できません）：INVALID_CONFIG（ブローカーから返されます）
ここでの提案：
1.例外をキャッチして、さらに数回試行する場合：再試行の回数を少し大きく設定します。
2.メッセージを直接破棄する場合：再試行回数の最初のポイント。
3.メッセージをどこかに保存してから、戻って処理を続行する場合は、停止して再試行できます。
KafkaのクロスデータセンターレプリケーションツールMirrorMakerは、デフォルトで無制限の再試行を実行します。
もちろん、失敗したメッセージの送信を再試行すると、リスクも発生します。たとえば、ネットワークの問題のためにプロデューサーがブローカーから確認を受信しなかったが、実際にはメッセージは正常に送信された後、プロデューサーは再試行します。再度正常に送信します。これは、ブローカーが2つの同一のメッセージを受信することを意味します。それではどうしますか？
回答：メッセージに一意の識別子を追加して、重複するメッセージを検出することができます。コンシューマーは、メッセージを読むときにそれらをクリーンアップできます。メッセージのべき等性を確認します。
小さな要約
プロデューサーの信頼性のために、システムの高信頼性の送信を本当に実現したい場合は、acks = allを合理的に設定し、同期されたコピーの最小数を設定し、システムが自動的に処理できないいくつかのエラーに対処することもできます、例：メッセージサイズエラー、認証エラー、シリアル化エラー、プロデューサーが再試行回数の上限に達した、またはメッセージ占有メモリが上限に達したなどのエラー。次に、これらのエラーは、プログラマーがコードレベルから解決する必要があります。
信頼できるシステムの消費者
Kafkaの信頼性を確保することを前提にデータを作成する方法について説明した後、同じ方法でデータを読み取る方法を見てみましょう。前回の記事から、Kafkaに送信されたデータ、つまり同期されたすべてのレプリカに書き込まれたデータのみがコンシューマーに利用可能であることがわかります。これは、消費者が受信したメッセージがすでに一貫していることを意味します。
消費者として何をしたいですか？
回答：実行する唯一のことは、どのメッセージが読み取られ、どのメッセージが読み取られなかったかを追跡することです。
そして、そのような追跡は、オフセットという概念と切り離せません。消費者には、信頼性に関連し、オフセットに関連する非常に重要ないくつかのパラメーターがあります。
- group.id
2つのコンシューマーが同じgroup.idを持ち、同じトピックにサブスクライブしている場合、各コンシューマーにはトピックパーティションのサブセットが割り当てられます。つまり、すべてのメッセージのサブセットのみを読み取ることができます。
- auto.offset.reset
1.この属性は、オフセットなしでパーティションを読み取る場合、またはオフセットが無効な場合にコンシューマーが行うべきことを指定します。
最新の値は2つあります。オフセットが無効な場合、コンシューマーは最新のレコードからデータの読み取りを開始します。
最も早い：オフセットが無効な場合、コンシューマーは開始位置からパーティションレコードを読み取ります。
- enable.auto.commit
1.この属性は、コンシューマーがオフセットを自動的に送信するかどうかを指定します。デフォルトはtrueです。
2.自動送信の主な欠点は、メッセージの繰り返し処理を制御できないことです。メッセージが処理のために別のバックグラウンドスレッドに渡されると、自動送信メカニズムがメッセージを処理する前にオフセットを送信する場合があります。
3.重複データまたはデータ損失を可能な限り回避するために（実際には、オフセットは2回送信または送信されません）、falseに設定できます。
- auto.commit.interval.ms
構成3でtrueを選択した場合、このパラメーターを使用して自動送信の頻度を構成できます。デフォルトでは、5秒ごとに1回送信します。
コンシューマーのいくつかの重要な構成パラメーターについて説明した後、オフセット角度を手動で送信します。注意すべき点がいくつかあります。
- 時間を処理した後は、必ずオフセットを送信してください。
- 送信の頻度は、パフォーマンスと繰り返されるメッセージの数の間のトレードオフです。
- 送信されたオフセットを必ずカウントしてください。
- 消費者のリバランスの問題を考えてみましょう。（リバランスは、消費者が増加または減少したときに発生します）
- メッセージのべき等性を確認します。たとえば、ワンキーシステム、リレーショナルデータベース、ES、キー値ストレージエンジンなどをサポートします。トピック+パーティション+オフセットの組み合わせを使用して、一意のキーを作成できます。つまり、この組み合わせにより、Kafkaレコードを一意に識別できます。
総括する
実際、この記事は以前の記事に基づいた基本的に小さな要約です。Kafkaのブローカー側、生産側、消費者側の3つのレベルから、いくつかの重要なポイントまたはパラメーターが提案され、Kafkaの信頼性が実行されます。 。
といった
- Kafkaのブローカーエンド：レプリケーションファクター、同期されたレプリカの最小数、および完全に選出されているかどうか。
- Kafkaのプロデューサー側：ackの影響、再試行の回数、およびコードで解決する必要のあるエラー。
- Kafkaのコンシューマー側：オフセット構成、オフセット送信方法、コンシューマー再試行の問題、べき等性を確保する方法など。
次の記事は、Kafkaのデータパイプライン（コネクタ）から作成されます。