共计 1146 个字符，预计需要花费 3 分钟才能阅读完成。
通常状况下，企业中会采取轮询或者随机的形式，通过 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 加随机后缀，使其平衡。