⼀般说到调优都离不开监控，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使⽤。

 

---