关于后端:Kafka调优策略解析

上一篇文章中，咱们为大家解说了 Kafka 的分区调配策略，StickyAssignor 调配策略、RoundRobinAssignor 调配策略、RangeAssignor 调配策略，具体内容加入 Kafka 分区调配策略详解，本片文章，咱们来看看 Kafka 的调优策略都有哪些。

⼀般说到调优都离不开监控，kafka 自身没有提供很好的图形化监控零碎，然而有很多第三⽅的 kafka 监控⼯具都做的绝对不错：

• Burrow
• Kafka Monitor
• Kafka Offset Monitor
• Kafka Eagle

在平时的开发中，开发者使⽤ 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

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 使⽤。

更多福利

云智慧已开源集轻量级、聚合型、智能运维为一体的综合运维治理平台 OMP（Operation Management Platform），具备 纳管、部署、监控、巡检、自愈、备份、复原 等性能，可为用户提供便捷的运维能力和业务管理，在进步运维人员等工作效率的同时，极大晋升了业务的连续性和安全性。点击下方地址链接，欢送大家给 OMP 点赞送 star，理解更多相干内容～

GitHub 地址：https://github.com/CloudWise-…
Gitee 地址：https://gitee.com/CloudWise/OMP

微信扫描辨认下方二维码，备注【OMP】退出 AIOps 社区运维治理平台 OMP 开发者交换群，与 OMP 我的项目 PMC 当面交换，和更多行业大佬一起交流学习～