⼀般說到調優都離不開監控，kafka本身沒有提供很好的圖形化監控系統，但是有很多第三⽅的kafka監控⼯具都做的相對不錯：

在平時的開發中，開發者使⽤kafka來發送資料已經⾮常熟悉，但是在使⽤的過程中，很多開發者並沒有深⼊的探索kafka使⽤過程中的引數配置，帶來的損失就是沒有充分的發揮出kfka的優勢，⽆法很好的滿⾜業務場景。

生產者配置與說明

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<String, String> producer = new KafkaProducer<String, String>
(props);

buffer.memory

Kafka的客戶端傳送資料到伺服器，⼀般要經過緩衝，當你通過KafkaProducer傳送出去的訊息是先進⼊到客戶端本地的記憶體緩衝⾥，然後把很多訊息收整合⼀個⼀個的Batch，再發送到Broker上去的。所以這個“buffer.memory”的本質就是⽤來約束KafkaProducer能夠使⽤的記憶體緩衝的⼤⼩的，它的預設值是32MB。既然瞭解了這個含義，試想⼀下，在⽣產項⽬⾥，這個引數應該怎麼來設定呢？

 

可以先想⼀下，如果這個記憶體緩衝設定的過⼩的話，可能會導致⼀個什麼問題？⾸先要明確⼀點，在記憶體緩衝⾥⼤量的訊息會緩衝在⾥⾯，形成⼀個⼀個的Batch，每個Batch⾥包含多條訊息。然後KafkaProducer的Sender執行緒會把多個Batch打包成⼀個Request傳送到Kafka伺服器上去。

 

 

如果要是記憶體設定的太⼩，可能導致⼀個問題，訊息快速的寫⼊記憶體緩衝⾥⾯，但是Sender執行緒來不及把Request傳送到Kafka伺服器。這樣是不是會造成記憶體緩衝很快就被寫滿？⼀旦被寫滿，就會阻塞⽤戶執行緒，不讓繼續往Kafka寫訊息了。所以對於“buffer.memory”這個引數應該結合⾃⼰的實際情況來進⾏壓測，需要測算⼀下在⽣產環境，你的⽤戶執行緒會以每秒多少訊息的頻率來寫⼊記憶體緩衝。假如說每秒300條訊息，那麼你就需要壓測⼀下，假設記憶體緩衝就32MB，每秒寫300條訊息到記憶體緩衝，是否會經常把記憶體緩衝寫滿？經過這樣的壓測，你可以調試出來⼀個合理的記憶體⼤⼩。

batch.size

batch.size是Batch資料量⼤⼩，預設值是16KB，⼀般可以嘗試把這個引數調節⼤⼀些，可以利⽤⾃⼰的⽣產環境發訊息的負載來測試⼀ 下。⽐如說傳送訊息的頻率就是每秒300條，那麼如果“batch.size”調節到了32KB，或者64KB，是否可以提升傳送訊息的整體吞吐量。理論上來說，提升batch的⼤⼩，可以允許更多的資料緩衝在⾥⾯， 那麼⼀次Request傳送出去的資料量就更多了，這樣吞吐量可能會有所提升。但是也不能⽆限⼤，過於⼤了之後，資料緩衝在Batch⾥傳送出去，那麼豈傳送訊息的延遲就會很⾼。

 

舉個例子，⼀條訊息進⼊了Batch，但是要等待5秒鐘Batch才湊滿了64KB，然後才傳送出去。那這條訊息的延遲就是5秒鐘。所以需要在這⾥按照⽣產環境的發訊息的速率，調節不同的Batch⼤⼩⾃⼰測⼀下最終出去的吞吐量以及訊息的延遲，設定⼀個最合理的引數。

linger.ms

要是⼀個Batch遲遲⽆法湊滿，此時就需要引⼊另外⼀個引數了“linger.ms”。它的含義是，Batch被建立之後，最多過多久，不管這個Batch有沒有寫滿，都必須傳送出去了。

 

舉個例⼦，一個batch.size是16kb，現在某個低峰時間段，傳送訊息很慢。這就導致可能Batch被建立之後，陸陸續續有訊息進來，但是遲遲⽆法湊夠16KB，難道此時就⼀直等著嗎？如果你現在設定“linger.ms”是50ms，那麼只要這個Batch從建立開始到現在已經過了50ms了，哪怕它還沒滿16KB，也要傳送出去了。所以“linger.ms”決定了你的訊息⼀旦寫⼊⼀個Batch，最多等待這麼多時間，他⼀定會跟著Batch⼀起傳送出去。避免⼀個Batch遲遲湊不滿，導致訊息⼀直積壓 在記憶體⾥傳送不出去的情況。

 

要配合batch.size⼀起來設定。舉個例⼦，⾸先假設一個Batch是32KB，我們需要估算下，正常情況下，⼀般多久會湊夠⼀個Batch，⽐如可能20ms就會湊夠⼀個Batch。那麼linger.ms就可以設定為25ms，也就是說，⼤部分的Batch在20ms內都會湊滿，但是你的linger.ms可以保 證，哪怕遇到低峰時期，20ms湊不滿⼀個Batch，還是會在25ms之後強制Batch傳送出去。

 

如果要是你 把linger.ms設定的太⼩了，⽐如預設就是0ms，或者你設定個5ms，那可能導致你的Batch雖然設定了32KB，但是經常是還沒湊夠32KB的資料，5ms之後就直接強制Batch傳送出去，這樣會導致你的Batch形同虛設，⼀直湊不滿資料。

max.request.size

最⼤請求大小 ：max.request.size，這個引數決定了每次傳送給Kafka伺服器請求的最⼤數值，同時也會限制你⼀條訊息的最⼤也不能超過這個引數設定的值，你可以根據⾃⼰的訊息的⼤⼩來靈活的調整。舉個例⼦，傳送的訊息都是⼤的報⽂訊息，每條訊息都是很多的資料，⼀條訊息可能都要20KB。此時你的batch.size是不是就需要調節⼤⼀些？

 

⽐如設定個512KB？然後你的buffer.memory是不是要給的⼤⼀些？設定128MB？只有這樣，才能讓你在⼤訊息的場景下，還能使⽤Batch打包多條訊息的機制。此時 “max.request.size”可以適當調⼤⼀些，⽐如調節到5MB。

retries與retries.backoff.ms

“retries”和“retries.backoff.ms”決定了重試機制，也就是如果⼀個請求失敗了可以重試⼏次，每次重試

的間隔是多少毫秒。

確認機制：acks

此配置是表明當⼀次produce請求被認為完成時的確認值。特別是，多少個其他brokers必須已經提交了

資料到他們的log並且向它們的leader確認了這些資訊。典型的值包括：

 

0： 表示producer從來不等待來⾃broker的確認資訊，這個選擇提供了最⼩的時延但同時⻛險最⼤（因

為當server宕機時，資料將會丟失）。

1：表示獲得leader replica已經接收了資料的確認資訊。這個選擇時延較⼩同時確保了server確認接收

成功。

-1：producer會獲得所有同步replicas都收到資料的確認。同時時延最⼤，然⽽，這種⽅式並沒有完全

消除丟失訊息的⻛險，因為同步replicas的數量可能是1。如果你想確保某些replicas接收到資料，那麼你 應該在topic-level設定中選項min.insync.replicas設定⼀下。

min.insync.replicas

當⽣產者設定應答為"all"(或“-1”)時，此配置指定了成功寫⼊的副本應答的最⼩數。如果沒滿⾜此最⼩數，則⽣產者將引發異常(NotEnoughReplicas或NotEnoughReplicasAfterAppend) min.insync.replicas和acks強制更⼤的耐⽤性時。典型的情況是建立⼀個副本為3的topic，將min.insync.replicas設定為2，並設定acks為“all”。如果多數副本沒有收到寫⼊，這將確保⽣產者引發異常。

消費者端配置和說明

fetch.min.bytes:

每次fetch請求時，server應該返回的最⼩位元組數。如果沒有⾜夠的資料返回，請求會等待，直到⾜夠的 資料才會返回。

auto.commit.enable

如果為真，consumer所fetch的訊息的offset將會⾃動的同步到broker。這項提交的offset將在程序掛掉 時，由新的consumer使⽤。

 

---