关于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，以及服务器的等等方面，有时间再总结吧