Kafka中产生数据积压的原因以及解决方案

Kafka中产生数据积压的原因以及解决方案

1、kafka中数据积压的原因

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

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

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

2、kafka中数据积压的解决方案

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

1、生产者producer：吞吐量
	可以通过修改以下参数配置提提升生产者的吞吐量：
	
	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没满，那么也必须把消息发送出去了，不能让消息的发送延迟时间太长，也避免给内存造成过大的一个压力。

2、消费者consum	：扩容，扩分区；增加consumer

	1）提升消费者组中的消费者数以及Topic中的分区数，让二者相等，假设设置为3个分区 = 3CPU。
	
	2）提高消费者拉取数据的能力，比如Flume每次拉取的数据可以由1000条改为3000条、Spark中将限流的参数增大、Flink中保证数据的处理效率等。

3、数据积压分析V2.0

	日常系统正常运转的时候，没有积压或者只有少量积压很快就消费掉了，但是某一个时刻，突然就开始积压消息并且积压持续上涨。

	这种情况下需要你在短时间内找到消息积压的原因，迅速解决问题才不至于影响业务。

	导致突然积压的原因肯定是多种多样的，不同的系统、不同的情况有不同的原因，不能一概而论。

	但是，我们排查消息积压原因，是有一些相对固定而且比较有效的方法的。

	能导致积压突然增加，最粗粒度的原因，只有两种：

	1、要么是发送变快了，2、要么是消费变慢了。

	大部分消息队列都内置了监控的功能，只要通过监控数据，很容易确定是哪种原因。

	如果是单位时间发送的消息增多，比如说是赶上大促或者抢购，短时间内不太可能优化消费端的代码来提升消费性能，唯一的方法是通过扩容消费端的实例数来提升总体的消费能力。

	如果短时间内没有足够的服务器资源进行扩容，没办法的办法是，将系统降级，通过关闭一些不重要的业务，减少发送方发送的数据量，最低限度让系统还能正常运转，服务一些重要业务。

	还有一种不太常见的情况，你通过监控发现，无论是发送消息的速度还是消费消息的速度和原来都没什么变化，这时候你需要检查一下你的消费端，是不是消费失败导致的一条消息反复消费这种情况比较多，这种情况也会拖慢整个系统的消费速度。

	如果监控到消费变慢了，你需要检查你的消费实例，分析一下是什么原因导致消费变慢。

	优先检查一下日志是否有大量的消费错误，如果没有错误的话，可以通过打印堆栈信息，看一下你的消费线程是不是卡在什么地方不动了，比如触发了死锁或者卡在等待某些资源上了。