您的位置:  首页 > 技术 > 前端 > 正文

【Kafka核心原理解析】之调优策略解析

2022-01-25 12:00 https://my.oschina.net/yunzhihui/blog/5412159 云智慧AIOps社区 次阅读 条评论
上一篇文章中,我们为大家讲解了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

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,了解更多相关内容~
 
 
微信扫描识别下方二维码,备注【OMP】加入AIOps社区运维管理平台OMP开发者交流群,与OMP项目PMC当面交流,和更多行业大佬一起交流学习~
 
展开阅读全文
  • 0
    感动
  • 0
    路过
  • 0
    高兴
  • 0
    难过
  • 0
    搞笑
  • 0
    无聊
  • 0
    愤怒
  • 0
    同情
热度排行
友情链接