kafka千万级数据积压原因以及解决方案

一、原因

kafka作为消息队列，其中数据积压也是经常遇到的问题之一。

我们都知道，数据积压的直接原因，一定是系统中的某个部分出现了性能问题，来不及处理上游发送的数据，才会导致数据积压。

那么我们就需要分析在使用kafka时，如何通过优化代码以及参数配置来最大程度的避免数据积压来对业务中的影响。

二、解决方案

1.1、通过优化代码

数据积压可能是我们在编写代码处理逻辑的时候，代码质量不高，处理速度慢导致消费数据的性能低，可以优化代码。

1.2、优化kafka配置参数

1.2.1、优化生产者producer的参数

首先我们在上面分析得出，是由于上游生产者producer发送数据过快，以及下游消费者consumer拉取数据过慢，实质上就是，生产者生产数据速度>>消费者消费数据速度。那么就可以把问题定位到生产者producer以及消费者consumer这两方面上。

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

1）batch.memory修改缓冲区大小

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

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

2）compression.type压缩格式

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

3）batch.size批次大小

设置merge batch合并批次消息的大小

如果 batch 批次太小，会导致频繁网络请求，吞吐量下降；

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

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

4）linger.ms等待时长

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

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

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

1.2.2、优化消费者cousumer

扩容，扩分区；增加consumer

1）提升消费者组中的消费者数以及Topic中的分区数，让二者相等，假设设置为3个分区 = 3CPU。
什么是分区？
分区就是一个topic的数据被分成多少份的单元，比如一个topic的数据被分成3份，那么就是3个分区，一个分区对应一份的数据。而每个分区中的写入的数据是有顺序的，分区之间数据是无序。

2）提高消费者拉取数据的能力，比如Flume每次拉取的数据可以由1000条改为3000条、Spark中将限流的参数增大、Flink中保证数据的处理效率等。