动态创建Kafka监听容器无@KafkaListener时能否使用@RetryableTopic

@RetryableTopic 无法直接在你当前手动创建容器的场景下生效。
该注解的处理逻辑与@KafkaListener深度绑定：Spring Kafka是在KafkaListenerAnnotationBeanPostProcessor解析@KafkaListener标注的监听器方法时，同步完成重试/死信Topic自动创建、重试路由逻辑织入、延迟转发容器生成等一系列配置的。你通过ConcurrentKafkaListenerContainerFactory<String, Serializable>#createContainer(final String... topics)手动创建容器、再调用容器setupMessageListener方法配置监听器的流程，完全不会触发@RetryableTopic的解析逻辑，就算给类或方法加了注解也不会生效。

你可以根据自己的需求选择以下两种方案实现目标：

• 保留现有手动创建容器的开发模式，手动实现重试逻辑
  @RetryableTopic本身没有特殊的黑科技，本质是封装了一套标准化的重试+死信队列流转规则：按配置的退避策略生成对应延迟级别的重试Topic，消费失败的消息按已重试次数转发到对应延迟的重试Topic，重试次数耗尽后转发至死信Topic。你完全可以参照这套逻辑手动实现：自行创建对应重试、死信Topic的监听容器，在消息处理逻辑里捕获业务异常后，按配置的退避规则计算下次投递时间，给消息带上重试次数、原始Topic等必要请求头后转发到对应队列即可。唯一的成本是需要自己处理Topic按需创建、重试计数校验、路由判断这些细节，避免出现消息无限循环重试的问题。
• 改用编程式注册Kafka监听端点，原生复用RetryableTopic能力
  如果不想手动维护重复的重试转发逻辑，可以放弃手动调用createContainer的方式，改为在应用启动阶段通过KafkaListenerEndpointRegistrar动态注册KafkaListenerEndpoint实例，把你需要动态指定的Topic列表、消息处理逻辑、退避策略、异常捕获规则、死信队列配置等@RetryableTopic对应的参数都绑定到注册的端点上。这种方式走的是和声明式写@KafkaListener完全一致的底层处理流程，可以直接复用@RetryableTopic的全部能力，不需要额外编写重试转发的通用逻辑。

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