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

57次阅读

共计 4169 个字符,预计需要花费 11 分钟才能阅读完成。

上一篇文章中,咱们为大家解说了 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 当面交换,和更多行业大佬一起交流学习~

正文完
 0