使用spark.streaming.kafka.consumer.poll.ms和reconnect.backoff.ms解决spark streaming消费kafka时任务不稳定的问题

问题描述

在用spark streaming程序消费kafka的数据时，遇到了一个神奇的现象：同样的数据量、相似的数据，在消费时，有些批次的数据在做map操作时神奇的多了40多秒，具体看下面的数据：在map操作时，有些是几秒，有些稳稳的是41s！如果是偶然出现还好，但是，大部分的作业都是在map时花了刚好41s。这就很神奇了。

1.map:2s	
2.map:41s		
3.map:0.8s	
4.map:41s	
5.map:41s	

解决方法一

看了篇博客，里面博主说：

第一，减小spark.streaming.kafka.consumer.poll.ms参数到3000ms以内，即3秒超时就重试，第二，将spark.task.maxFailures改为10，默认值是4，加大重试次数，修改完这两个参数后基本上解决了这个问题，多数批次在阻塞重连后都能很快读到消息并运行成功

我试了下，

sc.set("spark.streaming.kafka.consumer.poll.ms", "1000")

然后，有些task直接崩了。但是并不影响后面的计算，因为它会重试。

java.lang.IllegalArgumentException: requirement failed: Failed to get records for spark-executor-consume-kafka-01 orcl_ogg_info 0 60980 after polling for 1000

解决方法二

虽然使用spark.streaming.kafka.consumer.poll.ms这个参数可以解决，但是我并没有用，而是用了另一个。
参考这里
需要将kafka的一个叫reconnect.backoff.ms的参数值设为0，我的java代码如下：

public static Map<String, Object> initKafkaParams(String kafkaServers,String kafkaGroupId,String autoOffsetReset) {
		Map<String, Object> kafkaParams = new HashMap<>();
		kafkaParams.put("bootstrap.servers", kafkaServers);
		kafkaParams.put("key.deserializer", StringDeserializer.class);
		kafkaParams.put("value.deserializer", StringDeserializer.class);
		kafkaParams.put("group.id", kafkaGroupId);
		kafkaParams.put("auto.offset.reset", autoOffsetReset);
		kafkaParams.put("enable.auto.commit", false);
		kafkaParams.put("reconnect.backoff.ms", "0");
		return kafkaParams;
	}

参数分析

spark.streaming.kafka.consumer.poll.ms

这个参数我看了下这篇文章，按我的理解大致如下：
spark去kafka取数的时候，会有一个超时时间。如果两次尝试后都出现了超时，这个任务就会失败，然后spark会把这个任务分发到其它的executor上面去执行，这就会导致一定的调度耗时。
在spark中这个参数的默认值是512ms。如果超时时间很短，但是kafka响应的时间很长，这就会导致spark中有很多的任务失败。如果超时时间太长，spark在这段时间内什么都不做且最终还是会超时，就会产生很大的延迟（poll timeout+executor中的任务调度）。
如果spark作业中有很多的任务失败，你需要去增大这个值（或者你该去kafka那边看看为啥它那么久都没响应）。

如果不指定这个参数，spark可能就会使用spark.network.timeout（所有网络交互的默认超时，默认是120s）

reconnect.backoff.ms

如果客户端与kafka的broker的连接断开了，客户端会等reconnect.backoff.ms之后重新连接。

reconnect.backoff.max.ms

重连的总的最大时间，每次连接失败，重连时间都会指数级增加，每次增加的时间会存在20%的随机抖动，以避免连接风暴。

---

2020 10 15 更新
最近发现，如果将reconnect.backoff.ms设为0，在集群压力大的情况下，有很多任务失败时，会出现大量连接涌向kafka，而且大部分重新连接也会失败，这就造成可能导致kafka挂掉或者spark这边重试次数用完后spark job挂掉从而导致程序挂掉。所以如果在集群压力大时，可以考虑将spark.streaming.kafka.consumer.poll.ms调大一点。