Spring Kafka批量消费抛出MyKafkaRetryException重试耗尽未进入DLT问题

问题根因 #

你遇到的无限重试问题是Spring Kafka 2.6.x版本RecoveringBatchErrorHandler的常见特性与bug导致，核心原因有三个：

1. 异常被外层逻辑包装，默认分类器无法识别嵌套的MyKafkaRetryException
   你配置的分类器默认只会校验直接抛出的异常类型，如果你的业务异常被事务管理器、AOP切面等包装成UndeclaredThrowableException、TransactionSystemException等上层异常，分类器会匹配失败，误将可重试异常判定为无限重试类型。
2. 退避策略的最大耗时配置错误
   你使用的ExponentialBackOff以总运行时长作为重试终止条件，如果calculateMaxElapsedTime()计算得到的数值过大（比如误设为Long.MAX_VALUE），会导致退避策略永远不会触发终止逻辑，进入无限重试。
3. 2.6.9版本内置分类器的逻辑缺陷
   该版本的分类器不会递归遍历异常因果链，仅能匹配最上层异常类型，无法匹配嵌套的自定义异常。

解决步骤 #

• 校验异常包装情况
  在onMessage抛出异常的位置、RecoveringBatchErrorHandler分类逻辑处加调试日志，打印完整异常栈，确认MyKafkaRetryException是否为直接抛出的最上层异常。
• 自定义支持递归匹配的分类器
  替换默认的分类规则，递归遍历异常因果链匹配自定义重试异常：

BinaryExceptionClassifier classifier = new BinaryExceptionClassifier(
    ImmutableMap.of(MyKafkaRetryException.class, true), false);
// 开启遍历因果链配置
classifier.setTraverseCauses(true);
errorHandler.setExceptionClassifier(classifier);

• 校验退避策略配置
  打印RetryProperties计算得到的maxElapsedTime数值，确认其符合你的预期重试总时长，可临时替换为FixedBackOff做验证：

// 临时验证用：重试3次，每次间隔1s
FixedBackOff fixedBackOff = new FixedBackOff(1000L, 3);
RecoveringBatchErrorHandler errorHandler = new RecoveringBatchErrorHandler(consumerRecordRecoverer, fixedBackOff);

如果替换为固定次数退避后重试耗尽后正常进入DLT，说明原ExponentialBackOff的maxElapsedTime计算逻辑有误，调整对应配置即可。

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