実際のKafka開発では、プロデューサーでもコンシューマーでも、多くのパラメーターを設定してPropertiesオブジェクトを構築する必要があることがわかります。
このコードには、一般的に使用される多くのパラメーター構成があります。オンラインで使用する場合、実際のデータ量とデータサイズに応じて、これらの構成の特定の値を決定する必要があります。詳細に分析するために、より重要なパラメーターを選びましょう。
Properties props = new Properties();
//集群地址，多个服务器用"，"分隔
props.put("bootstrap.servers", "192.168.72.141:9092,192.168.72.142:9092,192.168.72.143:9092");
//重新发送消息次数，到达次数返回错误
props.put("retries", 0);
//Producer会尝试去把发往同一个Partition的多个Requests进行合并，batch.size指明了一次Batch合并后Requests总大小的上限。如果这个值设置的太小，可能会导致所有的Request都不进行Batch。
props.put("batch.size", 163840);
//Producer默认会把两次发送时间间隔内收集到的所有Requests进行一次聚合然后再发送，以此提高吞吐量，而linger.ms则更进一步，这个参数为每次发送增加一些delay，以此来聚合更多的Message。
props.put("linger.ms", 1);
//在Producer端用来存放尚未发送出去的Message的缓冲区大小
props.put("buffer.memory", 33554432);
//key、value的序列化，此处以字符串为例，使用kafka已有的序列化类
props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");
//props.put("partitioner.class", "com.kafka.demo.Partitioner");//分区操作，此处未写
props.put("acks", "1");
props.put("request.timeout.ms", "60000");
props.put("compression.type","lz4");
1.プロデューサーのパラメーター確認設定
メッセージが「コミット」されたと見なされる前にプロデューサーがリーダーから確認する必要がある、プロデュース要求に対する応答の数。このパラメーターは、メッセージの永続性を制御するために使用されます。現在、3つの値が提供されています。
- acks = 0：リーダーからの確認を待たずに、プロデュースリクエストがすぐに返されることを示します。このスキームは最高のスループット率ですが、メッセージが実際に正常に送信されたかどうかは保証されません。
- acks = -1：パーティションリーダーは、メッセージがすべてのISRレプリカ（同期されたレプリカ）に正常に書き込まれるのを待ってから、生成要求が成功したと見なすことを示します。このソリューションは、最高のメッセージ耐久性保証を提供しますが、理論的にはスループット率も最悪です。
- acks = 1：これは、リーダーコピーがこの生成リクエストに応答し、ローカルログにメッセージを書き込む必要があることを意味します。その後、生成リクエストは成功したと見なされます。リーダーのコピーが要求に応答した後に死亡した場合、メッセージは失われます。このプログラムは、優れた耐久性の保証とスループットを提供します。
推奨構成：
より高い耐久性要件が必要で、データ損失要件がない場合は、acks = -1を設定します。その他の場合は、acks = 1に設定します。
2.プロデューサーのパラメーターbuffer.memory設定（スループット）
このパラメーターは、メッセージをキャッシュするためにプロデューサーが使用するバッファーのサイズをバイト単位で指定するために使用されます。デフォルト値は33554432で、合計は32Mです。Kafkaは非同期メッセージアーキテクチャを使用します。prducerが起動すると、最初にメモリバッファーを作成して送信するメッセージを保存し、次に専用スレッドが実際の送信のためにバッファーからメッセージを読み取ります。
メッセージを継続的に送信するプロセスでは、バッファーがいっぱいになると、プロデューサーは空きメモリが解放されるまで直ちにブロッキング状態になります。この期間は、max.blocks.msで設定された値を超えることはできません。超過すると、プロデューサーはTimeoutExceptionをスローします。 、Producerはスレッドセーフであるため、TimeoutExceptionを報告し続ける場合は、buffer.memoryの増加を検討する必要があります。
ユーザーが複数のスレッドを使用してKafkaプロデューサーを共有すると、buffer.memoryがいっぱいになるのは簡単です。
3.プロデューサーパラメーターのcompression.type設定
プロデューサーコンプレッサーは現在、なし（圧縮なし）、gzip、snappy、lz4をサポートしています。
2016年8月、FaceBookはZtandardをオープンソース化しました。公式ウェブサイトテスト：Ztandard圧縮比は2.8、snappyは2.091、LZ4は2.101
4.プロデューサーパラメーターの再試行設定
プロデューサーの再試行回数が設定されます。再試行すると、一時的な理由により、プロデューサは以前に失敗したメッセージを再送信します。一時的な障害の理由には、メタデータ情報の障害、コピー数の不足、タイムアウト、境界外への移動、不明なパーティションなどが含まれます。retries> 0が設定されている場合、プロデューサはこれらの場合に再試行を試みます。
5.プロデューサーパラメータのbatch.size設定
プロデューサーはすべてバッチで送信されるため、バッチサイズの選択はプロデューサーのパフォーマンスにとって重要です。プロデューサーは、同じパーティションに送信された複数のメッセージをバッチにカプセル化します。バッチがいっぱいになると、プロデューサーはメッセージを送信します。ただし、別のパラメーターlinger.msに関連しているため、いっぱいになるまで必ずしも待機するわけではありません。デフォルト値は16Kで、合計は16384です。
6、プロデューサーパラメーターlinger.ms設定
プロデューサーはそれをバッチに従って送信しますが、これはlinger.msの値にも依存します。デフォルトは0で、これは滞在しないことを意味します。この場合、一部のバッチには送信前に十分なプロデュースリクエストが含まれていない可能性があり、その結果、小さなバッチが多数発生し、ネットワークIOに大きな負荷がかかります。
推奨構成：
ネットワークIOを削減するには、TPS全体を改善します。linger.ms = 5が設定されていると仮定すると、プロデューサーリクエストが5msの遅延で送信される可能性があります。