Kafka ソースコード分析——プロデューサー

序文

Kafka では、メッセージを生成するパーティはプロデューサーと呼ばれます。プロデューサーは、Kafka のコア コンポーネントの 1 つであり、メッセージのソースです。その主な機能は、クライアントのリクエストをパッケージ化してカプセル化し、kafka クラスター内の特定のトピックの特定のパーティションに送信することです。では、これらのプロデューサーによって生成されたメッセージはどのようにして Kafka サーバーに到達するのでしょうか?

プロデューサーの全体的なプロセス

Kafka でメッセージを送信および消費するプロセス

ソース コードの核となる観点から見ると、プロデューサーは次の核となる部分に分割できます。

1. プロデューサーの初期化
2. プロデューサーの送信プロセス
3. プロデューサーバッファ
4. プロデューサーのパラメーターとチューニング

プロデューサーの初期化

ソースコードには追加処理がたくさんあるため、ソースコードを解釈するためにすべての行を読む必要はなく、ソートというメインプロセスに従ってコアコードを見つけて解釈するだけで済みます。

パーティショナー (パーティショナー) を設定します。パーティショナーはカスタマイズをサポートします。

リトライ時間を設定する

再試行時間 (retryBackoffMs) のデフォルトは 100 ミリ秒です。ブローカーにメッセージを送信するときに例外がスローされ、それが再試行を許可する例外である場合、retries パラメーターで指定された最大回数だけ再試行されます。retryBackoffMs は再試行間隔です。

シリアライザーのセットアップ

インターセプターを設定する

インターセプターは通常、あまり使用されません。インターセプターは、メッセージにフィールドを一律に追加したり、成功した送信失敗の数をカウントしたりできます。これらのロジックは、プロデューサーのメッセージ送信効率を低下させるため、運用環境での使用はお勧めできません。

インターセプターを実装するには、まずProducerInterceptorインターフェイスを実装し、それをプロデューサーに設定する必要があります。

上の写真のいくつかの設定

1. 最大メッセージ サイズ (maxRequestSize) を設定します。デフォルトの最大値は 1M で、運用環境では 10M まで増やすことができます。

2. キャッシュ サイズ (totalMemorySize) を設定します。デフォルトは 32M です。

3. 圧縮形式の設定（compressionType）

4. RecordAccumulator を初期化します。つまり、バッファーは 32M として指定されます。

セットバッファ

メッセージアキュムレータの設定

プロデューサはバッファリングを通じて送信するため、メッセージの送信を完了するにはメッセージ アキュムレータが必要です。

クラスターのメタデータ（メタデータ）の初期化

送信者スレッドを作成する

ネットワークを管理するための重要なコンポーネントである NetworkClient もここで初期化されます。

KafkaThread は Sender をデーモン スレッドとして設定し、起動します

プロデューサーの送信プロセス

インターセプターロジックを実行する

インターセプター ロジックを実行し、メッセージを前処理し、プロデューサー レコードをカプセル化します。

クラスターのメタデータを取得する

Kafka Broker クラスターからクラスター メタデータのメタデータを取得する

連載

Serializer.serialize() メソッドを呼び出して、メッセージのキー/値のシリアル化を実行します。

パーティションの選択

Partition() を呼び出して、適切なパーティション戦略を選択し、メッセージ本文のプロデューサー レコードに送信するトピック パーティション番号を割り当てます。

メッセージはキャッシュに蓄積される

メッセージを RecordAccumulator コレクターにキャッシュし、最終的に送信するかどうかを決定します。

メッセージ送信

実際のメッセージ送信は Sender スレッドによって行われ、バッファと組み合わせて処理する必要があります。ここで必要なのは送信条件、つまりバッファのデータサイズがbatch.sizeに達しているか、linger.msの上限に達しているかだけです。

プロデューサーバッファ

Kafka プロデューサのバッファ、つまりメモリ プールは、主に接続作成時の不要なオーバーヘッドを回避するために、接続プール (DB、Redis) と比較できます。このようにして、メモリ プールは RecordBatch を再利用して、フル GC の問題を防ぐことができます。

コアは次のコードです。

Kafka のメモリ設計には、利用可能なメモリ (未割り当てメモリ、最初は 32M) と割り当てられたメモリの 2 つの部分があります。各小さなバッチは 16K で、各バッチは繰り返し使用できます。メモリは毎回申請する必要があり、2 つの部分は合計されます32Mまで。

メモリー申請の流れ

送信プロセス中に、メッセージはアキュムレータに入れられます。つまり、追加するために accumulator.append() が呼び出され、メッセージは送信用のバッチにカプセル化され、メモリが (free.allocate() に適用されます。 ））。

1. 要求されたメモリ サイズがキャッシュ プール全体のサイズを超える場合、例外がスローされます。
2. 要求されたサイズが各 RecordBatch のサイズ (16K) で、割り当てられたメモリが空でない場合は、メモリが 1 つ取り出され、直接返されます。
3. メモリ プール全体のサイズが申請するメモリ サイズより大きい場合 (this.availableMemory + freeListSize >= size)、使用可能なメモリから直接メモリを申請します。

プロデューサーパラメータの調整

Kafka を実際に使用する場合、プロデューサー側はスループットとメッセージ損失がないことを保証する必要があるため、いくつかのコア パラメーターの構成が重要です。

ありがとう

パラメータの説明: これは、Kafka プロデューサーにとって非常に重要なパラメータであり、指定されたパーティションに正常に書き込まれたメッセージのコピー数を示し、Kafka プロダクション側メッセージの耐久性を保証します。

最大リクエストサイズ

パラメータの説明: このパラメータは Kafka プロデューサにとっても重要で、プロダクション エンドが送信できる最大メッセージ サイズを示します。デフォルト値は 1048576 (1M) です。

チューニングの提案: この構成は運用環境としては少し小さいです。メッセージが大きすぎることによる送信の失敗を避けるために、運用環境では構成を適切に増やすことをお勧めします。たとえば、10485760 に調整できます ( 10M）。

再試行

パラメータの説明: 本番終了メッセージの送信に失敗した場合のリトライ回数を示します。デフォルト値は 0 (リトライなし) です。このパラメータは一般に、ネットワーク ジッター、リーダーの選出と再選出などの一時的なシステム障害によって引き起こされるメッセージ送信の失敗を解決するために使用されますが、その中で瞬間的なリーダーの再選出は比較的一般的です。したがって、このパラメータの設定は Kafka プロデューサーにとって非常に重要です。

チューニングの提案: 0 より大きい値 (3 倍など) に設定することをお勧めします。

retry.backoff.ms

パラメータの説明: ** 無効な頻繁な再試行を避けるために、2 つの再試行間の時間間隔を設定します。デフォルト値は 100 です。** 主に再試行と組み合わせて使用​​されます。再試行と retry.backoff.ms を設定する前に、最初に可能な値を見積もることが最善です。例外回復時間。プロデューサーが途中で再試行を中止しないように、合計再試行時間を例外回復時間よりも長く設定する必要があります。

接続数.max.idele.ms

パラメータの説明: 主にアイドル状態のリンクを閉じるのにかかる時間を決定するために使用されます。デフォルト値は 540000 (ミリ秒)、つまり 9 分です。

圧縮の種類

パラメータの説明:このパラメータは、運用側でメッセージを圧縮するかどうかを示します。デフォルト値は圧縮なし (なし) です。圧縮によりネットワーク IO 転送、ディスク IO、ディスク容量が大幅に削減され、全体的なスループットが向上しますが、CPU オーバーヘッドも犠牲になります。

チューニングの提案: スループットを向上させるには、運用側でメッセージを圧縮することをお勧めします。Kafka の場合、スループットと圧縮率を考慮して、lz4 圧縮を選択することをお勧めします。最高の圧縮率を追求する場合は、zstd 圧縮をお勧めします。

バッファ.メモリ

パラメータの説明:このパラメータは、運用終了メッセージ バッファ プールまたはバッファのサイズを示します。デフォルト値は 33554432 (32M) です。このパラメーターは基本的に、プロデューサー プログラムによって使用されるメモリ サイズと考えることができます。

チューニングの提案: 通常、運用側の全体的なスループットを確保するために最善を尽くす必要があります。このパラメータを適切に増やすことをお勧めします。これは、運用側クライアントがより多くのメモリを占有することも意味します。

バッチサイズ

パラメータの説明:このパラメータは、バッファに送信されたメッセージが 1 つずつバッチにカプセル化され、バッチでブローカーに送信されることを示します。デフォルト値は 16KB です。したがって、バッチ サイズを減らすとメッセージ遅延を減らすことができ、バッチ サイズを増やすとスループットを向上させることができます。

チューニングの提案: 一般に、このパラメータの値を適切に増やすと、運用側のスループットが大幅に向上します。たとえば、32KB に調整できます。値を増やすと、メッセージの遅延が比較的大きくなるということも意味します。

linger.ms

パラメータの説明:このパラメータは、バッチの制御に使用される最大アイドル時間を示します。この時間を超えるバッチも自動的にブローカーに送信されます。実際には、これはスループットと遅延の間のトレードオフです。デフォルト値は 0 で、バッチが満たされているかどうかに関係なく、メッセージをすぐに送信する必要があることを意味します。

チューニングの提案: 通常、リクエストの数を減らし、全体的なスループットを向上させるには、0 より大きい値 (たとえば、100 に設定する) を設定することをお勧めします。これにより、低負荷条件下で 100 ミリ秒の遅延が発生します。