关于kafka性能调优的一点总结

关于kafka的一些基础知识我想大家都知道,今天抽空整理下这些年使用kafka的一些调优技巧


首先明确一点,kafka的配置的核心点 在于 磁盘的刷新率 ,这也是影响kafka吞吐量的最最重要的一点!


而对于kafka的性能我们有两个指标,一个是延迟率,一个是吞吐量。所谓延迟率,就是处理一个事件需要多少事件。吞吐率则是说特定的时间内有多少事件到达。他们之间其实是相互平衡的。如果kafka有足够的broker去处理Topic,那么他一定是需要一定的延迟去处理这些消息的。


我们就从生产者和消费者两个方面来分析


生产者


kafka使用的是异步的发布-订阅模型。当我们send()一个消息的时候,结果是返回是在feature(参考java的feature任务)。生产者将消息发送给Broker,Broker等待事件,然后接收返回结果,然后相应事件,完成任务


batch.size


batch.size 也就是批量发送。这的批量发送,并不是批量的消息数,而是批量的字节数。他意味着他在向kafka发送消息之前会控制字节数,默认的是16348 byte (16k),在不超过可用内存下,我们是可以尽可能的设置高些。


当然了batch.size也不是越高越好的,如果我们的producer一直在发送消息,那么这时候吞吐量是能达到一个比较完美的情况,而如果producer经常闲置,也就是没有足够的数据来满足当前的内存分配,那么batch.siza将会白白占有很大的内存


Linger.ms


延迟等待时间。比如说我们100ms内设置100个batch的批量发送,只有达到100个的时候,我们才会发送,当然了他一定是要同一个partition。这边增加了消息的延迟,但是提高了吞吐量。有点像TCP的多路复用,但不是同一个,我们都是将多个请求,合并成一个


默认我们的是0ms,这也是为了保证消息的实时性。



消费者


所谓的消费者优化,其实说白了就是下游系统的消费能力。我们知道一个partition对应一个consumer,那么是不是consumer越多,消费能力就越强呢?当然不是了!一个Topic只存在于一个broker,如果broker无法做到水平扩展,那么再多的消费者,也只能等待,造成下游系统的压力增加,那么我们怎么在kafka的consumer做优化呢?


max.poll.interval.ms


我们在poll的时候,平均每个消息的处理时间。最合理的配置是两次消费之间的时间,因为如果设置过小,会导致group重新balance,而设置过大,则会导致group Rebalance


atuo.offset.reset


atuo,offset,reset 有两个参数 latest,erliest,一个表示从最近的记录开始拉取,一个表示从起始位置读取partition,如果不想要丢失那么是erliest,如果容忍一定程度的丢失那么就latest。他只适用于偏移量无效的情况下,那么他什么时候会无效,broker重新rebalance的时候。相应的数据量的不同,下游的处理效率,kafka的吞吐量也不一样


总结


kafka的调优不仅仅是这两个方面,还涉及到broker,以及服务器的等等方面,有时间再总结吧



暂无评论