Spring整合Kafka（十七）----处理异常_defaulterrorhandler

最新推荐文章于 2024-07-01 11:13:57 发布

文景中辉

最新推荐文章于 2024-07-01 11:13:57 发布

阅读量784

点赞数 15

分类专栏： 2024年程序员学习文章标签： spring kafka linq

本文链接：https://blog.csdn.net/2301_77054033/article/details/137776279

版权

本文介绍了如何在Spring中配置和使用DefaultErrorHandler来处理Kafka消费者监听异常，包括设置重试策略、回退操作和死信主题。同时，文章提供了相关的配置示例，如设置自定义的回退函数、监听器和异常处理。

摘要由CSDN通过智能技术生成

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新大数据全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip204888 （备注大数据）

正文

}


当容器配置为“AckMode.MMANUAL\_IMMEDIATE”时，可以配置错误处理程序来提交已恢复记录的偏移量；将commitRecovered属性设置为true。  
 另请参见[发布死信记录]( )。  
 使用事务时，DefaultAfterRollbackProcessor也提供类似的功能。请参阅[回滚后处理器]( )。  
 DefaultErrorHandler认为某些异常是fatal的，并跳过对此类异常的重试；在第一次失败时调用恢复器。默认情况下，被视为fatal的异常有：


* DeserializationException
* MessageConversionException
* ConversionException
* MethodArgumentResolutionException
* NoSuchMethodException
* ClassCastException  
 因为这些异常不太可能在重试delivery时得到解决。  
 你可以将更多异常类型添加到不可重试类别，或者完全替换已分类异常的映射。有关更多信息，请参阅DefaultErrorHandler.addNotRetryableException()和DefaultErrorHandler.setClassifications()的Javadocs，以及spring-retry BinaryExceptionClassifier的那些文档。  
 以下是一个将IllegalArgumentException添加到不可重试异常中的示例：

@Bean
public DefaultErrorHandler errorHandler(ConsumerRecordRecoverer recoverer) {
DefaultErrorHandler handler = new DefaultErrorHandler(recoverer);
handler.addNotRetryableExceptions(IllegalArgumentException.class);
return handler;
}


错误处理程序可以配置一个或多个RetryListener，接收重试和恢复进度的通知。

@FunctionalInterface
public interface RetryListener {

void failedDelivery(ConsumerRecord<?, ?> record, Exception ex, int deliveryAttempt);

default void recovered(ConsumerRecord<?, ?> record, Exception ex) {
}

default void recoveryFailed(ConsumerRecord<?, ?> record, Exception original, Exception failure) {
}

default void failedDelivery(ConsumerRecords<?, ?> records, Exception ex, int deliveryAttempt) {
}

default void recovered(ConsumerRecords<?, ?> records, Exception ex) {
}

default void recoveryFailed(ConsumerRecords<?, ?> records, Exception original, Exception failure) {
}

}


如果恢复器失败（引发异常），则失败的记录将包含在seek中。如果恢复器失败，默认情况下将重置BackOff，并且在再次尝试恢复之前，重新deliver将再次执行。若要在恢复失败后跳过重试，请将错误处理程序的resetStateOnRecoveryFailure设置为false。  
 你可以为错误处理程序提供BiFunction<ConsumerRecord<?, ?>, Exception, BackOff>，根据失败的记录或异常来确定要使用的BackOff：

handler.setBackOffFunction((record, ex) -> { … });


如果函数返回null，则将使用处理程序的默认BackOff。  
 将resetStateOnExceptionChange设置为true，如果异常类型在每次失败中发生变化，则重试序列将重新启动（包括选择新的BackOff，如果已配置）。如果为false，则不考虑异常类型。  
 另请参阅[投递尝试头Delivery Attempts Header]( )。


## 五、使用batch错误处理程序的转换错误Conversion Errors with Batch Error Handlers


将MessageConverter与ByteArrayDeserializer、BytesDeserializer或StringDeserializer以及DefaultErrorHandler一起使用时，batch监听器现在可以正确处理转换错误。当发生转换错误时，payload被设置为null，并且反序列化异常被添加到record header中，类似于ErrorHandlingDeserializer。监听器中有ConversionException的列表，因此监听器可以抛出BatchListenerFailedException，指出发生转换异常的第一个索引。

@KafkaListener(id = “test”, t