カフカの学習とコーミング

記事のディレクトリ

この記事では、kafkaの原則と概念を簡単に要約します。

1.Kafkaはメッセージキューです。

対応する特性は

高スループット：最大数十万のスループット
高い同時実行性：何千ものクライアントが同時に読み取りと書き込みを行えるようにサポートします
低遅延：最小遅延はわずか数ミリ秒です
メッセージの永続性と信頼性：メッセージはローカルディスクに永続化され、データのバックアップも同時にサポートされます
クラスターのフォールトトレランス：一部のノードに障害が発生することを許可する
スケーラビリティ：クラスターの動的拡張をサポート

2.カフカの主な用語

ブローカ
トピック
パーティション
消費者
プロデューサー
集まる
ニュース

Kafkaは分散メッセージミドルウェアです。メッセージはMYSQLに保存するデータのようなものです。kafkaサービスはクラスター内に存在し、クラスター内の各ノードはブローカーと呼ばれます。Kafkaでメッセージをアーカイブする方法は、トピックに従ってアーカイブされます（データベース内のテーブルのように）。同時に、各トピックを1つ以上のパーティションに分割できます（MYSQLではサブテーブルとして理解できます）。並列度（プロデューサーまたはコンシューマーの並列度）を上げるために使用されます。
メッセージのプロデューサーはプロデューサーと呼ばれ、メッセージのコンシューマーはコンシューマーと呼ばれます。プロデューサーはブローカー内のトピックのパーティションにメッセージを送信し、コンシューマーは1つ以上のトピックのパーティションからデータをプルするように指定します。Kafkaは、データの整然とした生成と消費を保証できます（もちろん、厳密に保証したい場合は、データをさらに理解して設定する必要があります）。カフカの簡単な図：
ここに画像の説明を挿入

3.カフカブローカー

kafkaブローカーレベルで行うことは、2つの比較的大きな側面に分けることができます。1つはクラスターの管理であり、もう1つはデータの管理です。

3.1トピックパーティションのデータ冗長性とリーダーパーティション

Kafkaは分散されているため、特定のデータ冗長性を使用して、クラスター内の一部のノードの障害に対処します。各トピックのreplica.factor = 3（またはその他）を設定することにより、各トピックは3になります。コピーが配置されているブローカーがダウンしている場合でも、サービスを提供できます（構成によっては、データが少し失われる可能性があります。これについては後で説明します）。各パーティションには複数のコピーがあり、Kafkaは、複数のコピーの中でリーダーコピーは1つしか存在できないと規定しており、すべての読み取りと書き込みはこのリーダーで実行されるためです。
Kafkaクラスター全体には、ほとんどの分散サービスが持つマスターの役割があります。彼は、コントローラーと呼ばれるクラスター全体のトピックパーティションのリーダー選出を担当します。

3.2クラスター内のコントローラー

すべての分散クラスターにマスターノードがあるように（zookeeperにはマスターノードがあり、esにもあります）、kafkaにもマスターの役割がありますが、kafkaではコントローラーと呼ばれます。コントローラーは、クラスターの可用性管理を担当していると見なすことができ、主に各パーティションのリーダー選出を担当しています。
では、kafkaの管理者はどのように選出されますか？動物園の飼育係のおかげで、選出機能が大幅に簡素化されました。起動時に、全員が動物園の飼育係に行き、同じ一時ノード（/ controller）を先制的に作成します。Zookeeperの分散整合性により、1つのリクエストのみが正常に作成され、成功した作成がコントローラーになり、他の失敗したノードがこのノードに監視を追加します。現在のコントローラーに障害が発生すると、この一時ノード（/ controller）は次のようになります。動物園の飼育係によって削除され、その後、誰もが再び競争することができます。
各選挙でコントローラーによって取得された新しいコントローラーは、それがzookeeperを介して新しいコントローラーであることを確認し、エポック+ = 1を入力します。ここでのエポックは、皇帝の年番号として簡単に理解できる値です。、各皇帝には独自のエポックがあり、次の皇帝のエポックは現在のエポックよりも大きくなっています。また、コントローラーはメッセージを送信するたびにこのエポックをもたらします。これは主にスプリットブレインを防ぐためです。つまり、新しいコントローラーが選択された後、古いスタックコントローラーが復活します。現時点では、彼はまだ考えているかもしれません。彼はコントローラーであり、他のノードに注文を出しますが、彼のエポックは比較的古く、そのような情報は他のノードによって無視されます。
エポックは、分散型のスプリットブレインを回避するために一般的に使用される方法であり、動物園の飼育係やいかだに適用されます。

3.3パーティション中的リーダー、フォロワー、同期レプリカ

リーダー、フォロワー、およびin-sync-replicaはすべてランタイムの概念であり、動的に変化します。静的ストレージでは、一般にレプリカと呼ばれます。
前述のように、フォールトトレランスを向上させるために、Kafkaにはパーティションごとに複数のレプリカがあります。（レプリカ）複数のレプリカの1つがリーダーになり、プロデューサーとコンシューマーからの各要求は常にリーダーパーティションによって処理されます。
プロデューサーがリーダーにメッセージを送信すると、リーダーはメッセージを独自のパーティションに保存し、フォロワーも常にリーダーからデータをプルします。つまり、リーダー内のデータを同期します。kafkaは一部のコピーをよりゆっくりと許可するため、サービスパフォーマンスサービスを向上させることができます。kafkain-sync-replicaは同期レプリカセットと呼ばれるフォロワーのサブセットを維持します。このコレクションにはリーダー自体も含まれます。リーダーはこれらのコピーがリーダーとの同期を維持しています。

1.リーダーは、フォロワーがin-sync-replicaセットに属するべきかどうかをどのように判断しますか？

以前のバージョンでreplica.lag.max.messages=5（或其他）は、メッセージが5つのメッセージでリーダーより遅れていることを設定することで判断でき、フォロワーは同期レプリカコレクションから追い出されます。
0.9以降、このパラメーターは破棄され、代わりに使用されますreplica.lag.time.max.ms=10000(默认是10s)。この構成は、in-sync-replicaのフォロワーが10秒以内にリーダーにデータをプルする要求を送信しない場合、フォロワーがinから追い出されることを示します。 -sync-replica。
このような最適化の利点は、メッセージフローのピークが瞬間的に発生した場合、同期レプリカ内のフォロワーのデータがリーダーよりも遅れる可能性が高く、その後キックアウトされ、その後に再び参加することです。リーダーに追いつく。ケースから追い出された-replica.lag.time.max.msこの問題を回避できるのであれば、それ自体を追加する必要はありません

2.リーダー選出

リーダーが電話を切ると、新しいリーダーはコントローラーがそれを選択する方法でありin-sync-replica、シートリーダーを選択することから、少しラフですがin-sync-replica、フォロワーが遅れる可能性があるため、リーダーにとっては、新しいリーダーが選択された後、そのデータが元のリーダーより遅れてデータが失われる可能性があります（成功メッセージがプロデューサーに返されましたが、最終メッセージは完了していません。永続性、コンシューマーはこのメッセージを消費できません）。もちろん、ブローカー側とプロデューサー側の協力が必要ないくつかの構成を通じてデータ損失を達成することができます。

3.最小ISR設定

ブローカー側で構成することもできますmin.insync.replicas。の場合min.insync.replicas=2、パーティションにデータを書き込むには、少なくとも2つの同期レプリカが必要です。この時点で同期されたコピーが1つしかない場合、ブローカーはプロデューサーからの要求の受け入れを停止します。この時点で、ブローカーは読み取り専用になります。データを送信しようとするプロデューサーはNotEnoughReplicasException例外を受け取りますが、コンシューマーは続行できます。既存のデータを読み取ります。
これは、不完全な選挙中のデータの書き込みと読み取りにおける予期しない動作を回避するためです。このパラメーターは、高可用性を実現するための重要な部分でもあることがわかります。設定するmin.insync.replicas=1と、リーダーがハングし、リーダーを選択できなくなります。

3.4パーティション内のメッセージの最高水準点

1.HighWatermarkとは何ですか。その用途は何ですか。

Kafkaのメッセージは、先着順、最高水準点、最高水準点の順にパーティションに継続的に保存されます。これにより、消費者が見ることができるメッセージの範囲が識別されます。データの整合性を可能な限り満たすために、メッセージがパーティションのリーダーのみであり、他のフォロワーに複製されていない可能性があります。現時点では、コンシューマーがこのメッセージを表示することは安全ではありません。このメッセージはプロデューサーが正常に永続化されたことを約束していない可能性があるため、この時点でリーダーがダウンすると、この時間がプロデューサーに返される可能性があるため、データの不整合も発生しますが、実際にはコンシューマーはこのデータを消費しました。そのため、Kafkaは、消費者が消費できるデータを特定するための最高水準点を設計しました。

2. HWの更新メカニズム：

1. LEO、log-end-offset

HWの更新メカニズムについて説明する前に、LEO（log-end-offset）を理解する必要があります。これは、パーティションの各レプリカに格納されているログの最後のログのオフセットです（最後に格納されています）。実際にはログのエントリです。シーケンス番号は、配列の添え字として理解できます。
プロデューサーがメッセージを送信するたびに、対応するサーバー（ブローカー）が指定されたパーティションに配置され、各メッセージがオフセットを生成します。
同時に、リーダーは独自のLEOだけでなく、他のフォロワーのLEO情報（この情報は、フォロワーがリーダーのデータをプルするときに渡されるフェッチオフセットでもあります）を持ち、リーダーはこれらに基づいてHWを完了します。 LEO情報の更新。HW = min（LEO）次の質問を通じてHWの更新に答えることができます

フォロワーはいつLEOを更新しますか
1. フォロワーレプリカの専用スレッドは、リーダーレプリカが配置されているブローカーにFETCH要求を継続的に送信し、独自のフェッチオフセットデータ（つまり、独自のLEO）を伝送します。
2. リーダーコピーは、フォロワーコピーにFETCH応答を送信します。
3. フォロワーは応答を取得した後、データを取り出してローカルの下部ログに書き込みます。その間、LEO値が更新されます。
リーダーは、自身の
リーダーによって記録されたフォロワーのLEOをどのように更新しますか？リーダー側の非自己複製オブジェクトのLEO値は、リーダー側のフォロワーのFETCH要求を処理するプロセス中に更新されます。
フォロワーはいつハードウェアを更新しますか
1. フォロワーレプリカオブジェクトは、ローカルLEOを更新した後、HWを更新します。
2. フォロワーがローカルログへのデータの書き込みを終了すると、HW値の更新を試みます。
3. アルゴリズムは、ローカルLEOおよびFETCH応答でリーダーのHW値の小さい方の値を取得することです。これは、フォロワーがフェッチするときにリーダーが独自のHWを渡すことを意味します。
リーダーはいつハードウェアを更新しますか
1. フォロワーのFETCH要求を処理するリーダーレプリカオブジェクトは、リーダーの非セルフレプリカオブジェクトのLEOを更新した後、自身のHW値を更新しようとします。
2. プロデューサーによって書かれたメッセージは、リーダーレプリカのLEOを更新します
3. コピーがISRから追い出されたとき
4. パーティションがリーダーコピーに変更された後
通常の同期HW更新プロセス中のリーダーの更新メカニズム
1. リーダーは、すべてのフォロワーのLEOに基づいてハードウェアを更新します

4プロデューサー

ここでの主な目的は、プロデューサーの送信メカニズムといくつかのより重要な構成を理解することです。

1.プロデューサーは、対応するトピックが配置されているノードにどのように直接接続しますか

プロデューサーは、仲介者を介した一連のルーティングや転送を行わずに、ブローカーのリーダーパーティションに直接メッセージを送信します。この機能を実現するために、

Kafkaクラスター内の各ブローカーは、プロデューサーの要求に応答して、トピックに関するメタ情報を返すことができます。このメタ情報には、稼働中のマシン、トピックのリーダーパーティション、およびで直接アクセスできるリーダーパーティションが含まれます。のこの段階。
プロデューサークライアント自体が、メッセージのプッシュ先のパーティションを制御します。実装方法は、ランダムな割り当て、ある種のランダムな負荷分散アルゴリズムの実装、またはいくつかのパーティショニングアルゴリズムの指定です。
1. Kafkaは、ユーザーがカスタムパーティションを実装するためのインターフェイスを提供します。ユーザーは、メッセージごとにpartitionKeyを指定し、このキーを使用していくつかのハッシュパーティションアルゴリズムを実装できます。たとえば、ユーザーIDがパーティションキーとして使用されている場合、同じユーザーIDを持つメッセージは同じパーティションにプッシュされます。
2. データをバッチでプッシュすると、処理効率が大幅に向上します。KafkaProducerは、特定の数のメッセージをメモリに蓄積した後、リクエストをバッチとして送信できます。バッチ数はプロデューサーのパラメーターで制御できます。パラメーター値は、累積メッセージ数（500など）、累積時間間隔（100msなど）、累積データサイズ（64KB）に設定できます。バッチサイズを増やすことで、ネットワーク要求の数とディスクIOを減らすことができます。もちろん、効率と適時性の観点から、特定のパラメーター設定を検討する必要があります。

2.関連する構成

acks:

acks = 0の場合、プロデューサーがメッセージをブローカーに送信すると、メッセージは成功したと見なされ、ブローカーの処理結果を待機しません。この場合、次の再試行の構成も無効です。この方法はスループットが最も高くなりますが、メッセージを失うのも最も簡単です。
acks = 1：プロデューサーは、パーティションのリーダーにメッセージを書き込んで成功を返した後、メッセージが正常に送信されたと見なします。グループリーダーがメッセージの書き込みに失敗した場合、プロデューサーはエラー応答を受け取り、再試行します。この方法では、メッセージの損失をある程度回避できますが、グループリーダーがダウンしているときにメッセージが他のコピーに複製されない場合でも、メッセージは失われます。
acks = all：プロデューサーは、すべてのコピーがメッセージを正常に書き込むのを待ちます。この方法は最も安全で、メッセージが失われないようにすることができますが、遅延も最大です。これは通常、データの永続性と一貫性のために使用されますA比較的高いシナリオですが、データスループットの要件は特に高くありません。

retries

プロデューサーがメッセージを送信して回復可能な例外を受信すると、プロデューサーは再試行します。このパラメーターは、再試行の回数を指定します。実際の状況では、このパラメーターをretry.backoff.ms（再試行待機間隔）と組み合わせて使用する必要があります。合計再試行時間は、クラスターがグループリーダーを再選出する時間よりも長くすることをお勧めします。プロデューサーが再試行を早く終了しないようにするため。失敗

batch.size

複数のメッセージがパーティションに送信される場合、プロデューサーはそれらをバッチで送信します。このパラメーターは、バッチメッセージサイズの上限（バイト単位）を指定します。バッチメッセージがこのサイズに達すると、プロデューサーはそれをブローカーに一緒に送信しますが、このサイズに達しない場合でも、プロデューサーはメッセージを送信するタイミングメカニズムを備えており、過度のメッセージ遅延を回避します。

linger.ms

このパラメーターは、プロデューサーがバッチメッセージを送信する前に待機する時間を指定します。このパラメーターが設定されている場合、バッチメッセージの指定されたサイズに達していない場合でも、プロデューサーは到着時間後にバッチメッセージをブローカーに送信します。デフォルトでは、プロデューサーのメッセージ送信スレッドは、メッセージが1つしかない場合でも、アイドル状態である限りメッセージを送信します。このパラメーターを設定した後、送信スレッドは一定時間待機します。これにより、メッセージをバッチで送信することでスループットを向上させることができますが、同時に遅延も増加します。

buffer.memory

このパラメータは、プロデューサがバッファに送信するメッセージのメモリサイズを設定します

client.id

このパラメーターは、メッセージの送信元のクライアントを識別するためにブローカーが使用する任意の文字列にすることができます。ブローカーがログ、メトリック、またはクォータ制限を印刷しているときに使用されます。

max.in.flight.requests.per.connection

このパラメーターは、プロデューサーがブローカーに送信して応答を待機できるメッセージの数を指定します。このパラメーターに高い値を設定すると、スループットが向上しますが、メモリ消費量も増加します。メッセージの順序を確認したい場合は、1にのみ設定できます。デフォルトは2.0の5です。Kafkaは、単一のプロデューサーの厳密な1回限りを保証し、比較的良好な順序も保証します。

max.request.size

このパラメーターは、プロデューサーによって送信されるデータパケットのサイズを制限します。データパケットのサイズは、メッセージのサイズとメッセージの数に関連しています。最大パケットサイズを1Mに指定すると、最大メッセージサイズは1Mになります。つまり、メッセージサイズが1Kの最大1000メッセージをバッチで送信できます。さらに、ブローカーには、受信したデータパケットのサイズを制御するためのmessage.max.bytesパラメーターもあります。実際には、プロデューサーがブローカーの制限を超えてデータサイズを送信しないように、これらのパラメーター値を一致させることをお勧めします。

5消費者

Kafkaの消費者、消費者は、その名前が示すように、Kafkaブローカーからプロデューサーによって生成されたデータを取得します。消費のデータ粒度はtopic.partitionに到達する可能性があり、同時に、開始位置のオフセット値を指定したり、時間に応じてオフセットを見つけて消費したりすることもできます。
各コンシューマーはグループIDを持ち、複数のコンシューマーはグループIDに属し、トピックの複数のパーティションを共有できます（並列処理を改善します）。
コンシューマーは、消費ポイントオフセットの自動送信を使用するか、手動送信を使用できます。彼にはackメカニズムがありません。オフセットが送信されるたびに、ブローカーのトピック__consumer_offset__へのメッセージが生成されます。次に起動すると、デフォルトでこのトピックから関連するオフセット情報を取得し、このオフセットを使用してブローカーからデータをプルします。

1.消費者のリバランスプロセス

1.リバランスのタイミング

1.通常の状態

组成员个数发生变化。例如有新的 consumer 实例加入该消费组或者离开组。
订阅的 Topic 个数发生变化。
订阅 Topic 的分区数发生变化。

2.消費者の驚き

session 过期
max.poll.interval 到期,在这个时间值达到时，心跳线程会自动停止发送heartbeats 然后 发送leave-group request

このとき、リバランスがトリガーされますが、

2.リバランスプロセス

説明のために新しい消費者を追加しましょう

コンシューマクライアントはグループへの参加要求を送信します。グループが存在しない場合、グループが作成され、グループのステータスは空です。
グループのメンバーが空であるため、メンバーがグループに追加され、現在のメンバー（クライアント）がグループのリーダーとして設定され、リバランス操作が実行されます。グループの状態はpreparingRebalanceになり、待機します。 rebalance.timeout.ms after（他のメンバーが参加グループを再送信するのを待つため。グループのステータスがpreparingRebalanceに変わった場合、コンシューマクライアントがポーリング操作を実行すると、needRejoin（）メソッドの結果はtrueを返します。これは、現在のコンシューマクライアントがグループに再参加する必要があることを意味します）、グループのメンバーが更新されました完了しました。この時点で、グループのステータスはAwaitingSyncに変わり、グループの参加応答をすべてのメンバーに返します。グループ;
クライアントは、グループへの参加の結果を受け取った後、その役割がグループのリーダーであることがわかった場合、割り当てを実行します。リーダーは、同期グループ要求を介して割り当ての結果をGroupCoordinatorに送信し、フォロワーはまた、同期グループをGroupCoordinatorリクエストに送信します（対応するフィールドが空であることを除く）。
GroupCoordinatorは、グループリーダーからのリクエストを受信すると、割り当ての結果を取得し、各メンバーに対応する割り当てを各メンバーに送信します。クライアントがフォロワーの場合、処理は行われません。グループのが安定します（つまり、リーダーの要求を受信した後にのみ、同期グループの結果がすべてのメンバーに返されます。これは1回だけ送信され、リーダーの要求によってトリガーされます）。

2.消費者のいくつかの構成

fetch.min.bytes

このパラメーターを使用すると、コンシューマーはブローカーからメッセージを読み取るときに最小量のデータを指定できます。コンシューマーがブローカーからのメッセージを読み取るときに、データ量がこのしきい値より少ない場合、ブローカーは十分なデータが得られるまで待機してから、コンシューマーにデータを返します。書き込み量が少ないトピックの場合、このパラメーターはラウンドトリップ時間を短縮するため、ブローカーとコンシューマーへのプレッシャーを軽減できます。消費者の数が多いトピックの場合、ブローカーのプレッシャーを大幅に減らすことができます。

fetch.max.wait.ms

上記のfetch.min.bytesパラメーターは、コンシューマーが読み取ることができるデータの最小量を指定し、このパラメーターは、コンシューマーが読み取るための最長の待機時間を指定することで、長期的なブロッキングを回避します。このパラメータのデフォルトは500msです。

max.partition.fetch.bytes

このパラメーターは、各パーティションによって返される最大バイト数を指定します。デフォルトは1Mです。つまり、KafkaConsumer.poll（）がレコードリストを返す場合、パーティションあたりのレコードバイト数は最大で1Mです。トピックに20個のパーティションと5個のコンシューマーが同時にある場合、各コンシューマーはメッセージを処理するために4Mのスペースを必要とします。実際には、コンシューマーがダウンしたときに他のコンシューマーがより多くのパーティションを使用できるように、より多くのスペースを設定する必要があります。
max.partition.fetch.bytesは、ブローカーが受信できる最大のメッセージ（max.message.sizeで設定）よりも大きくする必要があることに注意してください。大きくしないと、コンシューマーはメッセージを消費できません。さらに、上記の例に見られるように、通常、pollメソッドを呼び出して、メッセージをループで読み取ります。max.partition.fetch.bytesの設定が大きすぎると、コンシューマーが処理するのに時間がかかり、タイムリーなポーリングが行われず、セッションが期限切れになる可能性があります。この場合、max.partition.fetch.bytesを減らすか、セッション時間を長くしてください。

session.timeout.ms

このパラメーターは、コンシューマーセッションの有効期限を設定します。デフォルトは3秒です。つまり、コンシューマーがこの期間内にハートビートを送信しない場合、ブローカーはセッションが期限切れであると見なし、パーティションのバランスを取り直します。このパラメーターはheartbeat.interval.msに関連しており、heartbeat.interval.msは、KafkaConsumerのpoll（）メソッドがハートビートを送信する頻度を制御します。この値はsession.timeout.msよりも小さくする必要があります。通常は1/3です。 1秒。session.timeout.msを小さくすると、Kafkaは障害をすばやく見つけてバランスを取り直すことができますが、誤判断の可能性も高くなります（たとえば、消費者はダウンタイムではなくメッセージをゆっくり処理するだけです）。

auto.offset.reset

このパラメーターは、コンシューマーがパーティションを初めて読み取るとき、または最後の場所が古すぎる（たとえば、コンシューマーが長時間オフラインになっている）ときの動作を指定します。値は最新（最新ニュースからの消費）または最も早い可能性があります。（最も古いメッセージから消費を開始します）。

enable.auto.commit

このパラメーターは、コンシューマーが消費変位を自動的に送信するかどうかを指定します。デフォルトはtrueです。繰り返しの消費やデータ損失を減らす必要がある場合は、falseに設定できます。trueの場合、auto.commit.interval.msによって設定される自動送信の時間間隔に注意を払う必要がある場合があります。

partition.assignment.strategy

コンシューマーグループに複数のコンシューマーが存在する場合、特定の戦略に従ってトピックパーティションをコンシューマーに割り当てる必要があることはすでにわかっています。この戦略はPartitionAssignorクラスによって決定され、デフォルトで2つの戦略があります。
1. 範囲：トピックごとに、各コンシューマーは特定の連続範囲パーティションを担当します。コンシューマーC1とコンシューマーC2が2つのトピックにサブスクライブし、これら2つのトピックに3つのパーティションがある場合、この戦略を使用すると、コンシューマーC1が各トピックのパーティション0とパーティション1を担当します（添え字は0から始まります）。コンシューマーC2が担当します。パーティション2の場合。コンシューマーの数がパーティションの数で均等に分割されていない場合、最初のコンシューマーにはさらにいくつかのパーティションがあります（トピックの数によって決定されます）。
2. ラウンドロビン：サブスクライブされたすべてのトピックパーティションは、順番に1つずつコンシューマーに割り当てられます。上記の例を使用すると、コンシューマーC1は最初のトピックのパーティション0、パーティション2、および2番目のトピックのパーティション1を担当し、コンシューマーC2は他のパーティションを担当します。この戦略はよりバランスが取れており、すべてのコンシューマー間のパーティション数の差は最大で1であることがわかります。
partition.assignment.strategy割り当て戦略が設定されています。デフォルトはorg.apache.kafka.clients.consumer.RangeAssignor（スコープ戦略を使用）です。これをorg.apache.kafka.clients.consumer.RoundRobinAssignor（ポーリング戦略を使用）に設定するか、割り当て戦略を自分でpartition.assignment.strategy実装してから実装クラスを指すことができます。

client.id

このパラメーターは任意の値にすることができ、メッセージの送信元のクライアントを指定するために使用されます。通常、ログの印刷、インジケーターの測定、およびクォータの割り当て時に使用されます。

max.poll.records

このパラメーターは、poll（）呼び出しによって返されるレコードの数を制御します。これを使用して、プルループでアプリケーションによって処理されるデータの量を制御できます。

max.poll.interval.ms

2つのポーリング間の最大時間間隔。メッセージを処理する時間を長く設定します。この時点でpoll（）操作が実行されない場合、ハートビートの送信を自動的に停止し、グループ脱退要求を送信します
。2つのpoll（）の場合サーバーはこのパラメーターを他のコンシューマーの対応する拒否を待機する最大時間としても使用するため、処理要求は比較的大きいため、非同期で実行する必要があります。他のコンシューマーもmax.poll.interval.msを比較的大きく設定した場合長い場合、全体のリバランスに長い時間がかかる場合があります。

receive.buffer.bytes、send.buffer.bytes

これらの2つのパラメーターは、データの読み取りおよび書き込み時にTCPバッファーを制御し、システムのデフォルト値を使用するには-1に設定します。コンシューマーとブローカーが異なるデータセンターにある場合、データセンター間の一般的な遅延が比較的大きいため、バッファーをある程度増やすことができます。

partition.assignment.strategy

これにより、コンシューマー内のコンシューマーのパーティションの分散メカニズムが設定されます

理論的には、kafkaの圧縮と解凍は、個別に構成されていない限りブローカーによって処理されないため、CPUが増加する可能性があります
http://zhongmingmao.me/2019/08/02/kafka-compression/

6.高性能な読み書きの秘訣

シーケンシャル読み取りおよび書き込み
ゼロコピー

参考
https://juejin.im/post/5d9944e9f265da5b6a169271
https://juejin.im/post/5bf6b0acf265da612d18e931#heading-5
https://juejin.im/post/5c0683b1f265da614f701441
https://juejin.im/post/5c46e729e51d9c8e6e51d9c8e6