理解并避免Kafka中的CommitFailedException
[LOADING...]
1. 概述
Kafka 在消费者提交已处理消息的偏移量方面提供了高度灵活性。它包含同步、异步和自动提交选项。
虽然这降低了提交过程的复杂性,但意外错误仍可能发生。
在本教程中,我们将了解 Kafka 消费者应用程序中与提交偏移量相关的故障。我们将调试导致 CommitFailedException 的根本原因,并实现几种解决方案来尽可能避免该异常。
2. 实现一个消费者服务来演示问题
让我们构建一个简单的消费者应用程序,顺序处理记录。
我们将在 KafkaConsumerService 类中实现 consume 方法:
在上面的代码中,我们顺序处理记录,然后提交偏移量。
为了模拟数据库调用,我们将在上面的 simulateDBCall 方法中添加一个延迟:
该延迟会导致消费者在下一条记录之前等待大约 150 毫秒。
3. 测试服务
接下来,让我们测试消费者服务。请注意,我们在测试框架中使用了 Testcontainers 来提供本地 Kafka 代理进行测试;完整细节可在本文末尾链接的支持 GitHub 仓库中找到。
首先,我们在测试类中包含与消费者相关的配置:
在上述配置中,我们轮询一条记录,最大轮询间隔为 50 毫秒,并手动提交偏移量。
我们将通过生产、消费一条消息并验证偏移量来实现一个测试用例:
但偏移量并未提交,我们会看到以下错误日志,测试用例也会失败:
从上面的日志可以明显看出,CommitFailedException 是在 consume 方法中提交偏移量时抛出的。同时,它指出消费者不再是组的一部分。Kafka 在其类文档中给出了可能原因的提示。
4. CommitFailedException 的根本原因
我们可以通过多种方式监控和调试根本原因,包括容器日志、CLI 和 Kafka UI 工具。
首先,检查 Kafka 容器日志中的错误:
我们还可以使用 kafka-consumer-groups 命令确认消费者组的状态:
根据上述日志和状态,我们可以看到消费者因客户端特定错误被移除:消费者轮询超时已过期。
Kafka 有多种方式检查消费者是否健康并正常运行。这包括后台心跳检查,该检查应在会话超时之前运行。
此外,Kafka 期望消费者在指定的最大轮询间隔时间周期内轮询一次。 如果消费者因任何原因未轮询,它将被视为死亡,分区将重新分配给其他消费者。
通过进一步调试并重新验证应用程序日志,我们观察到记录处理明显花费了更多时间,并且消费者未能在指定的 MAX_POLL_INTERVAL_MS_CONFIG 时间周期内调用 poll 方法。因此,Kafka 组协调器移除了该消费者。
因此,任何进一步提交偏移量的尝试都会失败并出现该错误。这是有道理的,因为消费者不再是分区所有者,提交可能会破坏偏移量状态。
我们将探讨几种实际的方法来防止该错误。## 5. 避免问题的方法
在理解消费者轮询后,我们将通过分析消费者代码和配置来尝试解决该问题。
我们可以考虑启用自动提交配置,但这会带来数据丢失和提交时机不规律的可能性。此外,此方法无法确保至少一次处理。
相反,我们将探讨一些相关的手动提交解决方案。
5.1. 调整轮询时长和批量大小
通过调试代码,我们发现实际处理时间显著长于指定的最大轮询间隔。
我们将增加最大轮询间隔配置:
我们还可以根据批处理时间和吞吐量需求来微调批量大小。
现在测试更新后的消费者,确认不再抛出 CommitFailedException。
需要注意的是,通常将轮询间隔设置为批处理时间的3倍左右,以确保有安全的缓冲时间。
虽然调整轮询间隔有效,但在更复杂的场景下(例如涉及数据库事务或网络调用的处理)仍可能遇到问题。
5.2. 异步处理
如果我们在执行 I/O 操作的同一线程中处理记录,上述解决方案会降低吞吐量并增加延迟。
在生产环境中,无法保证数据库执行时间可预测,因此仅配置轮询时长可能不足。
我们可以考虑对记录进行异步处理,这样消费者线程的阻塞时间会大大缩短。
在 Kafka 中,可以通过虚拟线程异步处理记录来实现。
首先,我们在消费者服务中包含一个工作线程池和每个分区的偏移量跟踪映射:
接下来,我们更新 consume 方法,使用工作线程进行异步处理:
我们实现 processAsync 方法来异步处理记录:
在上述代码中,消费者等待工作线程完成处理,然后提交已处理的偏移量。如果处理过程中任何记录失败,我们会记录失败消息并将其发送到死信队列(DLQ)主题。
接下来,实现 markComplete 方法,将已处理记录的偏移量更新到 committableOffsets 映射中:
最后,实现 commitOffsets 方法来提交已处理的偏移量:
在上述方法中,我们为所有已处理的记录构建提交偏移量的快照映射并提交。同时,以原子方式将已提交的偏移量标记为完成。
现在,在测试类中配置消费者,增加批量大小和最大轮询间隔:
最后,我们通过生产并消费多条消息来验证偏移量,实现一个测试用例:
运行上述测试后,我们成功验证了提交的偏移量与消费的消息总数一致。
5.3. 实现 ConsumerRebalanceListener
应当注意,在消费者中实现 ConsumerRebalanceListener 始终是良好的实践,用于提交任何正在处理的偏移量并清理数据。
我们在 KafkaConsumerService 类的 KafkaConsumer 对象中实现 ConsumerRebalanceListener:
还需要实现 commitOffsets 方法,为特定分区提交偏移量:
在上述代码中,我们通过从特定分区的偏移量创建快照映射来提交偏移量。
现在,运行上一节的测试方法,验证更新后的消费者实现的偏移量:
从上述测试可以看出,所有消息都已处理并提交。
5.4. 最佳实践
虽然无法完全避免异常,但我们可以保护系统免受重复处理、数据丢失或静默消息丢弃的影响。
我们应该在生产者端和消费者端实现幂等性,验证数据库约束,并确保无副作用的重试处理。此外,应将失败的消息发送到重试或死信队列主题。
6. 结论
在本文中,我们学习了消费者应用中一种常见的偏移量提交相关异常。我们探讨了 CommitFailedException 发生的原因以及如何预防。我们还通过调整最大轮询间隔和切换到异步处理逻辑实现了预防方案。
与往常一样,示例代码可在 GitHub 上找到。