通常状况下，企业中会采取轮询或者随机的形式，通过Kafka的producer向Kafka集群生产数据，来尽可能保障Kafk分区之间的数据是均匀分布的。
在分区数据均匀分布的前提下，如果咱们针对要解决的topic数据量等因素，设计出正当的Kafka分区数量。大数据培训对于一些实时工作，比方Spark Streaming/Structured-Streaming、Flink和Kafka集成的利用，生产端不存在长时间"挂掉"的状况即数据始终在继续被生产，那么个别不会产生Kafka数据积压的状况。
然而这些都是有前提的，当一些意外或者不合理的分区数设置状况的产生，积压问题就不可避免。
Kafka音讯积压的典型场景：
1.实时/生产工作挂掉
比方，咱们写的实时利用因为某种原因挂掉了，并且这个工作没有被监控程序监控发现告诉相干负责人，负责人又没有写主动拉起工作的脚本进行重启。
那么在咱们重新启动这个实时利用进行生产之前，这段时间的音讯就会被滞后解决，如果数据量很大，可就不是简略重启利用间接生产就能解决的。
2.Kafka分区数设置的不合理（太少）和消费者"生产能力"有余
Kafka单分区生产音讯的速度qps通常很高，如果消费者因为某些起因（比方受业务逻辑复杂度影响，生产工夫会有所不同），就会呈现生产滞后的状况。
此外，Kafka分区数是Kafka并行度调优的最小单元，如果Kafka分区数设置的太少，会影响Kafka consumer生产的吞吐量。
3.Kafka音讯的key不平均，导致分区间数据不平衡
在应用Kafka producer音讯时，能够为音讯指定key，然而要求key要平均，否则会呈现Kafka分区间数据不平衡。
那么，针对上述的状况，有什么好的方法解决数据积压呢？
个别状况下，针对性的解决办法有以下几种：
1.实时/生产工作挂掉导致的生产滞后
a.工作重新启动后间接生产最新的音讯，对于"滞后"的历史数据采纳离线程序进行"补漏"。
此外，倡议将工作纳入监控体系，当工作呈现问题时，及时告诉相干负责人解决。当然工作重启脚本也是要有的，还要求实时框架异样解决能力要强，防止数据不标准导致的不能从新拉起工作。
b.工作启动从上次提交offset处开始生产解决
如果积压的数据量很大，须要减少工作的解决能力，比方减少资源，让工作能尽可能的疾速生产解决，并赶上生产最新的音讯
2.Kafka分区少了
如果数据量很大，正当的减少Kafka分区数是要害。如果利用的是Spark流和Kafka direct approach形式，也能够对KafkaRDD进行repartition重分区，减少并行度解决。
3.因为Kafka音讯key设置的不合理，导致分区数据不平衡
能够在Kafka producer处，给key加随机后缀，使其平衡。