個人公衆番号:石杉のアーキテクチャノート(ID:shishan 100)

目次

1、背景導入:多くの学生がKafkaパラメータを読めない
2、Kafka生産端のサンプルコード
3、メモリバッファのサイズ
4、どのくらいのデータを1つのBatchにパッケージするのが適当ですか?
5、もし1つのBatchがなかなか埋まらなかったらどうしますか?
6、最大要求サイズ
7、再試行メカニズム
8、持続化メカニズム

1、背景導入:kafkaパラメータが読めない学生が多い

今日は皆さんに面白い話をして、多くの会社がKafkaをMQとして複雑な大型システムを開発していることを知っています.
Kafkaのクライアント記述コードを用いてサーバと対話する場合,クライアントに多くのパラメータを設定する必要がある.
だから私は多くの若い学生に会ったことがあります.チームに入ったばかりかもしれませんが、Kafkaという技術についてはあまり知りません.
この時、彼らはチームの中のいくつかのベテラン同僚が書いたコードを見て、何が起こっているのか分からないことができて、背後の意味を理解していません.この中には特にKafkaパラメータの設定があります.
そこで、この文章では、Kafkaの生産側でよく見られるパラメータの設定についてお話しし、次にKafkaクライアントが設定したパラメータを見たとき、これ以上怖がらないようにします.

2、Kafka生産端のサンプルコード

Properties props = new Properties();
props.put("bootstrap.servers", "localhost:9092"); 
props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("buffer.memory", 67108864); 
props.put("batch.size", 131072); 
props.put("linger.ms", 100); 
props.put("max.request.size", 10485760); 
props.put("acks", "1"); 
props.put("retries", 10); 
props.put("retry.backoff.ms", 500);
KafkaProducer producer = new KafkaProducer(props);

3、メモリバッファのサイズ

まず「buffer.memory」というパラメータを見てみましょう.どういう意味ですか.
Kafkaのクライアントがサーバにデータを送信するのは、一般的にバッファリングされています.つまり、KafkaProducerを通じて送信されたメッセージは、まずクライアントのローカルメモリバッファに入り、多くのメッセージを1つ1つのBatchに収集し、Brokerに送信します.
したがって、この「buffer.memory」の本質は、KafkaProducerが使用できるメモリバッファのサイズを制約するために使用され、彼のデフォルト値は32 MBです.
では、この意味を理解した以上、生産プロジェクトでは、このパラメータをどのように設定すればいいのか考えてみましょう.
まず考えてみてください.このメモリバッファの設定が小さすぎると、何か問題が発生する可能性がありますか.
まず、メモリバッファに大量のメッセージがバッファリングされ、1つ1つのBatchが形成され、各Batchに複数のメッセージが含まれていることを明確にします.
その後、KafkaProducerには、複数のBatchを1つのRequestにパッケージしてKafkaサーバに送信するSenderスレッドがあります.
メモリ設定が小さすぎると、メッセージがメモリバッファに急速に書き込まれるが、SenderスレッドがKafkaサーバにRequestを送信するのに間に合わないという問題が発生する可能性があります.
メモリバッファがすぐにいっぱいになるのではないでしょうか.書き込みがいっぱいになると,ユーザスレッドがブロックされ,Kafkaへのメッセージの書き込みを継続させない.
したがって、「buffer.memory」というパラメータは、自分の実際の状況と組み合わせて圧力測定を行う必要があります.本番環境では、ユーザー・スレッドがメモリ・バッファに1秒あたりどのくらいのメッセージを書き込むかを計算する必要があります.
例えば、毎秒300件のメッセージを測定する必要があります.メモリバッファが32 MBで、毎秒300件のメッセージをメモリバッファに書きます.メモリバッファをいっぱいに書きますか?このような圧力測定により、合理的なメモリサイズをデバッグできます.

4、どのくらいのデータを1つのBatchにパッケージするのが適当ですか?

次に2つ目の問題は、あなたの「batch.size」をどのように設定すればいいかということです.これはあなたのBatchごとにどれだけのデータを保存するかを決めて送信することができます.
例えば、Batchを16 KBのサイズに設定すれば、16 KBのデータを集めることができます.
このパラメータのデフォルト値は16 KBで、一般的にこのパラメータを大きく調整して、自分の生産環境でメッセージを送る負荷を利用してテストしてみることができます.
例えば、メッセージを送信する頻度が毎秒300件である場合、例えば「batch.size」が32 KBまたは64 KBに調整された場合、メッセージの全体的なスループットを向上させることができるかどうか.
理論的にはbatchのサイズを上げることで、より多くのデータをバッファリングすることができ、1回のRequestで送信されるデータ量がより多くなり、スループットが向上する可能性があります.
しかし、これも無限に大きくすることはできません.大きすぎると、データが常にBatchにバッファリングされて送信されないと、あなたがメッセージを送信する遅延が高くなります.
例えば、メッセージがBatchに入ったが、5秒待ってから64 KBがいっぱいになってから送信される.このメッセージの遅延は5秒です.
そこで、ここでは本番環境のメッセージ送信速度に応じて、異なるBatchサイズを調整して最終的なスループットとメッセージの遅延を自分でテストし、最も合理的なパラメータを設定する必要があります.

5、一つのBatchがなかなか埋まらなかったらどうする?

1つのBatchがなかなか満たされない場合は、別のパラメータを導入する必要があります.「linger.ms」
彼の意味は、1つのBatchが作成されてから、せいぜいどのくらい経っても、このBatchがいっぱい書いてあるかどうかにかかわらず、送らなければならないということです.
例えばbatch.sizeは16 kbですが、現在ある低ピーク期間で、メッセージの送信が遅いです.
これにより、Batchが作成された後も、続々とメッセージが入ってくる可能性がありますが、なかなか16 KBに届かないので、この時ずっと待っていたのではないでしょうか.
もちろんそうではありません.もしあなたが今「linger.ms」を50 msに設定しているとしたら、このBatchが作成から今まで50 msを過ぎている限り、彼がまだ16 KB未満であっても、彼を送ります.
だから「linger.ms」はあなたのメッセージを1つのBatchに書き込むと、せいぜいこんなに多くの時間を待っていて、彼は必ずBatchと一緒に送信することを決定しました.
1つのBatchが遅れて不満を募らせ、メッセージがメモリに蓄積されて送信されないことを避けます.これは重要なパラメータです.
このパラメータはbatchに合わせて非常に慎重に設定するのが一般的である.sizeを一緒に設定します.
例を挙げると、まずあなたのBatchが32 KBだと仮定すると、通常の状況では、通常どのくらいで1つのBatchに届くかを試算しなければなりません.例えば、正常には20 msで1つのBatchに足りるかもしれません.
ではあなたのlinger.msは25 msに設定できます.つまり、通常、ほとんどのBatchは20 ms以内にいっぱいになりますが、linger.msは,低ピーク時に20 msが1つのBatchに満たなくても,25 ms後に強制的にBatchを送信することを保証できる.
もしあなたがlinger.msの設定が小さすぎます.例えば、デフォルトは0 msです.あるいは、5 msを設定すると、Batchが32 KB設定されている可能性がありますが、32 KBのデータが足りないことがよくあります.5 ms後、直接Batchを送信するように強制します.これはよくありません.実は、Batchが虚構で、データに不満を持っています.

6、最大要求サイズ

「max.request.size」というパラメータは、Kafkaサーバに送信されるたびに要求される最大サイズを決定し、メッセージの最大サイズもこのパラメータ設定の値を超えてはいけないことを制限します.これは、実際には自分のメッセージのサイズに応じて柔軟に調整することができます.
例を挙げると、あなたの会社が送ったメッセージは大きなメッセージで、どのメッセージも多くのデータで、1つのメッセージは20 KBかかるかもしれません.
この時あなたのbatch.sizeは大きく調節する必要がありますか?例えば512 KBを設定しますか?そしてあなたのbuffer.memoryは大きいのではないでしょうか.例えば128 MBを設定しますか?
このようにしてこそ、大きなメッセージのシーンで、Batchを使用して複数のメッセージをパッケージ化するメカニズムを使用することができます.しかし、このとき「max.request.size」も同期して増加しなければならないのではないでしょうか.
あなたの1つの要求が大きいかもしれないので、デフォルトは彼が1 MBなので、5 MBに調整するなど、適切に大きくすることができますか?

7、再試行メカニズム

「retries」と「retries.backoff.ms」は、再試行メカニズムを決定します.つまり、リクエストが失敗した場合、再試行間隔はミリ秒です.
これは皆さんが適当に何回か再試行する機会を設けて、一定の再試行間隔を与えればいいです.例えば、100 msの再試行間隔を与えればいいです.

8、持続化メカニズム

「acks」パラメータは、送信されるメッセージがどのような永続化ポリシーを採用するかを決定します.これは多くの他の概念に関連しています.これは、以前に「acks」のために書いた文章を参照してください.
履歴書にKafkaを書くと、面接官はacksパラメータがメッセージの持続化に与える影響を説明する可能性があります.
END
下の図を押して公衆番号に注目することを歓迎します:石杉のアーキテクチャのノート!
公衆番号の楽屋は資料に返事して、作者の独占秘制の学習資料を獲得します
石杉のアーキテクチャノート、BATアーキテクチャの経験を共有