kafkaクラスタProducerの基本データ構造とワークフローの深い分析-kafkaビジネス環境の実戦
4247 ワード
本セットの技術コラムは著者(秦凱新)の普段の仕事の総括と昇華であり、実際のビジネス環境からケースを抽出して総括と分かち合い、ビジネス応用の最適化提案とクラスタ環境容量計画などの内容を提供することによって、本セットのブログに引き続き注目してください.IOT時代で最も戦闘力のあるチームに参加することを期待しています.QQメールアドレス:[email protected]学術交流があれば、いつでも連絡することができます.
1 Producerエンド基本データ構造 ProducerRecord:1つのProducerRecordは送信されるメッセージレコードを表し、主に5つのフィールドから構成される: RecordMetadata:Kafkaサーバ側がクライアントに返すメッセージのメタデータ情報は、前の3つが比較的重要であり、Producer側はこれらのメッセージを使用してメッセージの送信に成功した後の処理を行うことができる.
2 Producer側メッセージ送信プロセス send()のメッセージ送信アクションがトリガーされる前に、props属性で指定されたserversを介してbrokerクラスタに接続し、ZookeeperからクラスタMetedata情報を収集し、どのbrokerがどのTopicのどのpartitionを管理するか、およびbrokersの健康状態を知る. の下には流水ライン操作があり,ProducerRecordオブジェクトキャリアtopic,partition,messageなどの情報が,Serializerという「職場」でシーケンス化されている. シーケンス化されたProducerRecordオブジェクトは、Partitionrの「作業場」に入り、前述したPartitioningポリシーに従って、このメッセージがどのPartitionに割り当てられるかを決定する. は、partitionのProducerRecordが1つのバッファに入ることを決定し、IOを減らすことによって性能を向上させ、この「職場」では、メッセージがTopicPartition情報に従って分類整理され、同じTopicで同じparitionのProducerRecordが同じRecordBatchに置かれ、送信されるのを待つ.いつ送りますか.いずれもProducerのpropsで指定されており、デフォルト値があり、明らかに自分で指定できる. 一旦、単一RecordBatchのlinger.msの到着遅延またはbatch.sizeが上限に達すると、このRecordBatchはすぐに送信されます.また、全てのRecordBatchを一体とするとbufferに達する.memroyまたはmax.block.ms上限では、すべてのRecordBatchが送信されます. ProducerRecordメッセージは、割り当てられたPartitionに従って特定のbrokerに送信され、brokerは保存メッセージを受信し、Metadata情報を更新し、Zookeeperに同期する. Producerエンドその他の最適化ポイント: 3メッセージバッファ再プロファイリング producerが作成されると、buffer.memoryパラメータで指定されたデフォルト32 MBのaccumulatorバッファが作成され、送信するメッセージを保存します. このデータ構造には、メッセージロット情報(batches)という特に重要な集合情報も含まれている.この集合は本質的にHashMapであり,各topicパーティションのbatchキュー,すなわち前述のロットはtopicパーティションに従ってグループ化されている.これにより、異なるパーティションに送信されたメッセージは、対応するパーティションの下のbatchキューに保存される. メッセージM 1,M 2がtestの0パーティションに送信されるが異なるbatchに属し、M 3がtestの1パーティションに送信されると仮定すると、batchesに含まれる情報は、{「test-0」->「[batch 1,batch 2]、「test-1」->「[batch 3]} である batchごとに最も重要な3つのコンポーネントは、 を含む.本セットの技術コラムは著者(秦凱新)の普段の仕事の総括と昇華であり、実際のビジネス環境からケースを抽出することによって総括と共有を行い、ビジネス応用の最適化提案とクラスタ環境容量計画などの内容を提供し、本セットのブログに引き続き注目してください.IOT時代で最も戦闘力のあるチームに参加することを期待しています.QQメールアドレス:[email protected]学術交流があれば、いつでも連絡することができます. SenderスレッドはKafkaProducerが作成されてからずっと実行されています.そのワークフローは基本的にそうです: Senderスレッドは、対応するbrokerにPRODUCEリクエストを送信し、broker処理が完了した後、対応するPRODUCE responseを送信します.Senderスレッドがresponseを受信と、batchのコールバックメソッド が順次(メッセージ送信順に)呼び出される.
4まとめ SenderスレッドはKafkaProducerが作成してからずっと実行しており、単一RecordBatchのlinger.msの到着遅延またはbatch.sizeが上限に達すると,バックグラウンドスレッドとして即時送信が検出される. accumulatorバッファは、Topic partionに従ってパケット化され、あるBrokerに集中的に送信される. 本文は胡夕の関連技術のブログと書籍を学ぶことを通じて、行った学習ノートの総括、苦労して文を成し遂げて、本当に容易ではありませんて、それぞれ大切にして、ありがとうございます. 秦凱新于深セン20181203018
1 Producerエンド基本データ構造
topic topic
partition
key
value
timestamp
offset
timestamp
topic + partition topic
checksum CRC32
serializedKeySize
serializedValueSize
2 Producer側メッセージ送信プロセス
(1) batch.size: RecordBatch
(2) buffer.memory: RecordBatch
(3) linger.ms RecordBatch
(4) max.block.ms RecordBatch
(5) acks：Producer ，0 ， ， ， ， 。1 leader ， 。2 leader follwer ， ”all”。
(6) retries： 。
(7) retry.backoff.ms： ， ， ， ， ， 。
(8) max.in.flight.request.per.connection： ， Producer 。
(9) compression.type producer ， gzip, snappy lz4。 ， CPU ， IO 。
compressor:
batch ： batch.size ，
thunks：
(1)
(2) batch leader broker
(3) batch Socket broker
(4) response
4まとめ