Spark 2应用因Kafka分区新leader选举报错终止，是否每次选举都会失败？

首先明确：并不是每次Kafka分区选举新Leader，Spark应用都会失败，这个错误是特定场景下的偶发问题，而非必然结果。

为什么你的应用这次会失败？ #

你的应用已经稳定运行25小时并完成数据写入，说明基础配置是能正常工作的。这次失败的核心原因是：当Kafka进行Leader选举时，Spark消费者在尝试获取分区的Leader偏移量时，遇到了短暂的元数据不一致或超时——新Leader已经选举完成，但消费者本地缓存的集群元数据还没更新，导致无法定位到新Leader的偏移信息，最终触发了Couldn't find leader offsets for Error错误。

至于很多用户说遇到这个错误后无法重启应用，大概率是因为偏移量管理出了问题：比如消费者偏移量存储的位置（Kafka内置的__consumer_offsets主题或外部存储）和当前集群元数据不匹配，或者重启时消费者组没有正确触发元数据刷新，导致无法找到有效的起始偏移位置。

解决和预防方案 #

给你几个针对性的配置调整和优化建议，能有效避免这类问题：

• 调整元数据刷新频率：在Spark的Kafka消费者参数中设置metadata.max.age.ms=30000（默认是5分钟，调小到30秒），让消费者更频繁地同步Kafka集群的元数据，Leader选举后能更快感知到新的Leader节点。
• 优化偏移量提交策略：如果用自动提交，确保enable.auto.commit=true，同时设置auto.commit.interval.ms=10000（每10秒提交一次）；如果是手动提交，一定要在数据成功写入Kudu后再提交偏移量，避免偏移量和实际处理的数据不一致。
• 增加重试与超时配置：添加retry.backoff.ms=1000（每次重试间隔1秒）和request.timeout.ms=30000（请求超时30秒），让消费者遇到Leader选举这类临时故障时，有足够的时间重试获取元数据，而非直接终止。
• 重启时强制指定起始偏移：如果重启应用仍报错，可以在读取Kafka的配置里设置startingOffsets为latest或earliest，甚至直接指定具体的偏移量，强制消费者跳过有问题的偏移位置，重新启动消费流程。
• 确保Kudu写入的幂等性：虽然这次问题出在Kafka端，但建议给Kudu写入逻辑加上幂等校验（比如根据主键去重），避免应用重启后导致数据重复写入。

补充一句：你的应用之前能稳定运行这么久，说明架构本身是没问题的，这次更像是一次偶发的元数据同步延迟。调整上述配置后，后续遇到Leader选举时，应用应该能自动恢复，不会再直接失败。

内容的提问来源于stack exchange，提问作者Cheater