提升 Kafka 生产者的吞吐量

通过修改如下的参数配置就可以提升生产者的吞吐量。

buffer.memory

该参数用来设置生产者内存缓冲区的大小，生产者用它缓冲要发送到服务器的消息。

如果应用程序发送消息的速度超过发送到服务器的速度，会导致生产者空间不足。

这个时候 send() 方法调用要么被阻塞，要么抛出异常，取决于如何设置 block.on.buffer.full 参数(在 0.9.0.0 版本里被替换成了 max.block.ms ，表示在抛出异常之前可以阻塞一段时间)。

设置发送消息的缓冲区，默认值是33554432，就是32MB

如果发送消息出去的速度小于写入消息进去的速度，就会导致缓冲区写满，此时生产消息就会阻塞住，所以说这里就应该多做一些压测，尽可能保证说这块缓冲区不会被写满导致生产行为被阻塞住

compression.type

默认情况下，消息发送时不会被压缩。

该参数可以设置为 snappy 、 gzp 或 1z4 ，它指定了消息被发送给 broker 之前使用哪一种压缩算法进行压缩。

snappy 压缩算法由 Google 发明，它占用较少的 CPU ，却能提供较好的性能和相当可观的压缩比，如果比较关注性能和网络带宽，可以使用这种算法。

gzip 压缩算法一般会占用较多的 CPU ，但会提供更高的压缩比，所以如果网络带宽比较有限，可以使用这种算法。

使用压缩可以降低网络传输开销和存储开销，而这往往是向 Kafka 发送消息的瓶颈所在。

默认是none，不压缩，但是也可以使用lz4压缩，效率还是不错的，压缩之后可以减小数据量，提升吞吐量，但是会加大producer端的cpu开销。

batch.size

当有多个消息需要被发送到同一个分区时，生产者会把它们放在同一个批次里。

该参数指定了一个批次可以使用的内存大小，按照字节数计算(而不是消息个数)。

当批次被填满，批次里的所有消息会被发送出去。

不过生产者并不一定都会等到批次被填满才发送，半满的批次，甚至只包含一个消息的批次也有可能被发送。

所以就算把批次大小设置得很大也不会造成延退，只是会占用更多的内存而已。

但如果设置得太小，因为生产者需要更频繁地发送消息，会增加一些额外的开销。

设置merge batch的大小，如果 batch 太小，会导致频繁网络请求，吞吐量下降；

如果batch太大，会导致一条消息需要等待很久才能被发送出去，而且会让内存缓冲区有很大压力，过多数据缓冲在内存里

默认值是：16384，就是16kb，也就是一个batch满了16kb就发送出去，一般在实际生产环境，这个batch的值可以增大一些来提升吞吐量，可以自己压测一下。

linger.ms

该参数指定了生产者在发送批次之前等待更多消息加入批次的时间。

KafkaProducer 会在批次填满或 linger.ms 达到上限时把批次发送出去。

默认情况下，只要有可用的线程，生产者就会把消息发送出去，就算批次里只有一个消息。

把 linger.ms 设置成比0大的数，让生产者在发送批次之前等待一会儿，使更多的消息加入到这个批次。

虽然这样会增加延退，但也会提升吞吐量(因为一次性发送更多的消息，每个消息的开销就变小了)。

这个值默认是0，意思就是消息必须立即被发送，但是这是不对的。

一般设置一个100毫秒之类的，这样的话就是说，这个消息被发送出去后进入一个batch，如果100毫秒内，这个batch满了16kb，自然就会发送出去。

但是如果100毫秒内，batch没满，那么也必须把消息发送出去了，不能让消息的发送延迟时间太长，也避免给内存造成过大的一个压力。

这篇好文章是转载于：学新通技术网