生產(chǎn)環(huán)境中使用Kafka，參數(shù)調(diào)優(yōu)非常重要，而Kafka參數(shù)眾多，我們的java的Configuration代碼中，經(jīng)常設(shè)置的參數(shù)如下：

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("retries", 10);props.put("retry.backoff.ms", 500);props.put("acks", "1"); KafkaProducer<String, String> producer = new KafkaProducer<String, String>(props);

?

• buffer.memory

　　Kafka的客戶(hù)端發(fā)送數(shù)據(jù)到服務(wù)器，不是來(lái)一條就發(fā)一條，而是經(jīng)過(guò)緩沖的，也就是說(shuō)，通過(guò)KafkaProducer發(fā)送出去的消息都是先進(jìn)入到客戶(hù)端本地的內(nèi)存緩沖里，然后把很多消息收集成一個(gè)一個(gè)的Batch，再發(fā)送到Broker上去的，這樣性能才可能高。

　　buffer.memory的本質(zhì)就是用來(lái)約束KafkaProducer能夠使用的內(nèi)存緩沖的大小的，默認(rèn)值32MB。

　　如果buffer.memory設(shè)置的太小，可能導(dǎo)致的問(wèn)題是：消息快速的寫(xiě)入內(nèi)存緩沖里，但Sender線程來(lái)不及把Request發(fā)送到Kafka服務(wù)器，會(huì)造成內(nèi)存緩沖很快就被寫(xiě)滿(mǎn)。而一旦被寫(xiě)滿(mǎn)，就會(huì)阻塞用戶(hù)線程，不讓繼續(xù)往Kafka寫(xiě)消息了。?

　　所以“buffer.memory”參數(shù)需要結(jié)合實(shí)際業(yè)務(wù)情況壓測(cè)，需要測(cè)算在生產(chǎn)環(huán)境中用戶(hù)線程會(huì)以每秒多少消息的頻率來(lái)寫(xiě)入內(nèi)存緩沖。經(jīng)過(guò)壓測(cè)，調(diào)試出來(lái)一個(gè)合理值。

?

• batch.size

　　每個(gè)Batch要存放batch.size大小的數(shù)據(jù)后，才可以發(fā)送出去。比如說(shuō)batch.size默認(rèn)值是16KB，那么里面湊夠16KB的數(shù)據(jù)才會(huì)發(fā)送。

??理論上來(lái)說(shuō)，提升batch.size的大小，可以允許更多的數(shù)據(jù)緩沖在里面，那么一次Request發(fā)送出去的數(shù)據(jù)量就更多了，這樣吞吐量可能會(huì)有所提升。

　　但是batch.size也不能過(guò)大，要是數(shù)據(jù)老是緩沖在Batch里遲遲不發(fā)送出去，那么發(fā)送消息的延遲就會(huì)很高。

　　一般可以嘗試把這個(gè)參數(shù)調(diào)節(jié)大些，利用生產(chǎn)環(huán)境發(fā)消息負(fù)載測(cè)試一下。

?

• linger.ms

　　一個(gè)Batch被創(chuàng)建之后，最多過(guò)多久，不管這個(gè)Batch有沒(méi)有寫(xiě)滿(mǎn)，都必須發(fā)送出去了。

　　比如說(shuō)batch.size是16KB，但是現(xiàn)在某個(gè)低峰時(shí)間段，發(fā)送消息量很小。這會(huì)導(dǎo)致可能Batch被創(chuàng)建之后，有消息進(jìn)來(lái)，但是遲遲無(wú)法湊夠16KB，難道此時(shí)就一直等著嗎？

　　當(dāng)然不是，假設(shè)設(shè)置“l(fā)inger.ms”是50ms，那么只要這個(gè)Batch從創(chuàng)建開(kāi)始到現(xiàn)在已經(jīng)過(guò)了50ms了，哪怕他還沒(méi)滿(mǎn)16KB，也會(huì)被發(fā)送出去。?

　　所以“l(fā)inger.ms”決定了消息一旦寫(xiě)入一個(gè)Batch，最多等待這么多時(shí)間，他一定會(huì)跟著B(niǎo)atch一起發(fā)送出去。?

　　linger.ms配合batch.size一起來(lái)設(shè)置，可避免一個(gè)Batch遲遲湊不滿(mǎn)，導(dǎo)致消息一直積壓在內(nèi)存里發(fā)送不出去的情況。

??

• max.request.size

　　決定了每次發(fā)送給Kafka服務(wù)器請(qǐng)求消息的最大大小。

　　如果發(fā)送的消息都是大報(bào)文消息，每條消息都是數(shù)據(jù)較大，例如一條消息可能要20KB。此時(shí)batch.size需要調(diào)大些，比如設(shè)置512KB，buffer.memory也需要調(diào)大些，比如設(shè)置128MB。?

　　只有這樣，才能在大消息的場(chǎng)景下，還能使用Batch打包多條消息的機(jī)制。

　　此時(shí)“max.request.size”也得同步增加。

?

• retries和retries.backoff.ms

　　重試機(jī)制，也就是如果一個(gè)請(qǐng)求失敗了可以重試幾次，每次重試的間隔是多少毫秒，根據(jù)業(yè)務(wù)場(chǎng)景需要設(shè)置。

?

• acks

acks	含義
0	?Producer 往集群發(fā)送數(shù)據(jù)不需要等到集群的返回，不確保消息發(fā)送成功。安全性最低但是效率最高。
1	?Producer 往集群發(fā)送數(shù)據(jù)只要 Leader 應(yīng)答就可以發(fā)送下一條，只確保 Leader 接收成功。
-1 或 all	?Producer 往集群發(fā)送數(shù)據(jù)需要所有的ISR?Follower 都完成從 Leader 的同步才會(huì)發(fā)送下一條，確保 Leader 發(fā)送成功和所有的副本都成功接收。安全性最高，但是效率最低。

?

?

轉(zhuǎn)載于:https://www.cnblogs.com/wwcom123/p/11181680.html

總結(jié)

以上是生活随笔為你收集整理的Kafka关键参数设置的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。