ACK（デフォルトは1です）
メッセージの前にプロデューサーがリーダーの確認要求いくつかの応答を取る、「提出」していると考えられます。このパラメータは、現在、三つの値を提供し、永続メッセージを制御するために使用されます。
ACK = 0：リーダーのいずれかの確認を待たずに、すぐにプロデューサー要求リターンを示します。このプログラムは、最高のスループットを持っていますが、メッセージが本当に正常に送信されていることを保証するものではありません。
ACK = -1：リーダーがメッセージを待つ必要があり、パーティションが正常に成功した要求のISRのレプリカ（複製の同期）の全てに書き込まれ表します。このアプローチは、理論的には、それを確実にするために、最高のメッセージの永続性を提供しますが、スループットは最悪です。
= 1のACK：要求メッセージにリーダー必見の応答を表し、ローカルログへの要求が成功すると考えられている書き込みます。この時点ではリーダーが要求に応答した後にハングアップする場合は、メッセージが失われます。プログラムの提供耐久性と保証スループットの間の良好な妥協。
buffer.memory（デフォルト値33554432）
このパラメータは、バイト単位で、メッセージプロデューサ端をバッファリングするバッファのサイズを指定し、デフォルト値は：33554432、合計32M。カフカのアーキテクチャは、真の送信専用のスレッドで構成されている場合、生産が開始され送信される最初のメッセージを保存するためのメモリバッファを作成し、メッセージを非同期で送信され使用し、バッファからのメッセージを読み取るための責任があります。空きメモリが解放されるまで、バッファがいっぱいになったときに、メッセージを送信するプロセスを続けると、プロデューサーはすぐにブロッキング状態に入り、この時間が複数回設定された値のmax.blocks.msを超えることはできません、プロデューサーは例外TimeoutExceptionがスローされます報告書はTimeoutException、buffer.memory引き上げを検討することが必要となっている場合プロデューサーは、スレッドセーフであるため。複数のスレッドシェアカフカプロデューサーの使用のユーザー、演奏buffer.memoryするのは簡単です。
max.block.ms（デフォルト値60000）
KafkaProducer.send（）と最大遮断時間のKafkaProducer.partitionsFor（）メソッドバッファが満杯であるか、またはメタデータのクラスタが利用できない場合、これら2つの方法がブロックされます。
batch.size（デフォルト値16384）
プロデューサーのバッチは、に従って送信されるので、バッチのサイズは、プロデューサーのパフォーマンスを選択することが重要です。同じ生産者宛のメッセージ複数のパッケージでバッチ、バッチが満杯である場合、メッセージが送信される生産者に分配されます。必ずしも必要ではないが満杯になるまで待って、これは関連する別の引数linger.msです。デフォルト値は16384 batch.size、合計16Kです。ターゲットトピックのプロデューサーは10のパーティション、データをキャッシュする必要があるメモリの16K * 10 = 160Kを送信した場合、この値は指定された値のbuffer.memoryより大きくすることはできません。
linger.ms（デフォルトは0です）
プロデューサーは、バッチに合わせて送信されますが、デフォルトでは、滞在していませ示しており、0である、linger.ms値を依存しています。この場合には、十分な生産の要求が含まれていないバッチを有していてもよい小バッチの多数で、その結果、送出された、ネットワークIOは大きな圧力をもたらします。値batch.sizeサイズに到達することができ、時間Tの間に生成されるデータの速度は、linger.msセットがTよりも小さくないかどうか、そうでなければbatch.sizeは無意味であろう。
compression.type（デフォルトはnone）
カフカの最後には、プロデューサーの圧縮の開放端を圧縮され、その後、データを圧縮して格納された圧縮ブローカー、ブローカーの終わりに送信され、消費者Brokerは、圧縮されたデータの終わりから私を得ました。これは、帯域幅を削減だけでなく、ブローカーのエンドディスク使用量を削減するだけでなく。現在なし（圧縮なし）、GZIP、てきぱきとLZ4をサポートしています。私たちは、gzipやLZ4を使用することをお勧めします。
再試行（デフォルトは2147483647です）
再試行のプロデューサーのセット数。再試行、プロデューサーのメッセージが再送信する前に過渡的な理由による失敗します。その理由瞬間的障害が含まれる：メタデータ情報に失敗し、コピーの数が少ない、残業、境界または未知のパーティションのうちシフトを。セットリトライ場合は> 0、そしてプロデューサーは、これらのケースをしようとしますし、再試行してください。プロデューサーとしてだけでなく、パラメータ：max.in.flight.requests.per.connection。パラメータが1より大きい場合、それは秩序の外にメッセージを送るに配置された再試行を引き起こす可能性があります。カフカのバージョン0.11.1.0は、「正確な意味の」サポートしているため、再試行メッセージ原因メッセージを繰り返し送信されません。
retry.backoff.ms（デフォルトは100です）
ネットワークサーバと調整が、調整は通常の状況下で必要ではない場合に応じて、2つの再試行時間間隔。
max.in.flight.requests.per.connection（デフォルトは5です）
プロデューサーIOスレッドは単一の応答ソケット接続に未解決の要求の最大数を送信することができます。つまり、要求の数は、サーバのネットワークへのクライアントは、最大することができます。プロデューサーの全体的なパフォーマンスを向上させるために、この値を大きくすると、スレッドスループットIOを増やす必要があります。前にいる場合でも、ちょうど、言いたいです。再試行メカニズムを開き、それは順序メッセージのうち引き起こす可能性が1よりも大きなパラメータを設定します。我々は、ボトルネックIOスレッドでプロデューサー、ならびに個々のブローカー・エンドの負荷を見つけた場合は5のデフォルト値は、出発点は良いです高くありませんが、あなたは適切に、このパラメータの値を大きくしようとすることができる大きすぎるメモリの増加、全体的な負担のプロデューサーになり、しばらくまた、不要なロックの競合が発生することがありますがTPSを削減します。
max.request.size（デフォルトは1048576です）
Borkerの最大値に送らプロデューサー単一の要求。ブローカClientRequestとしてパッケージの複数に属する送信者ProducerBatchスレッドは、複数のProducerBatchサイズが設定値max.request.sizeを超えることができません。message.max.bytes max.request.size設定値は、ブローカーの終わりよりも大きく設定すべきではありません。
enable.idempotence（デフォルトはfalse）
かどうかの冪等。trueに設定すると、プロデューサーは、各メッセージがあることを保証することを示し、たまたまコピーを持っています。falseに設定すると、それが原因でエラー発生時の再試行ブローカーのプロデューサーへの送信データは、それがマルチセクションの再試行メッセージ・データ・ストリームに書き込むことができ、作成することを示している場合。Enable.idempotence trueの場合、コンフィギュレーション項目max.in.flight.requests.per.connectionの要求値未満又は5に等しくなければならない; CI再試行値が0よりも大きくなければならない; CIは、に設定されなければならないACKを全。これらの値はユーザーによって明示的に設定されていない場合は、システムが自動的に適切な値を選択します。値が適切でない場合は、ConfigException例外がスローされます。
request.timeout.ms（デフォルト値30000）
プロデューサーブローカー、応答を待つ最大時間に要求を送信した後。
