Question

我正在建立一个卡夫卡消费者。我已经设置了类似于下面的恢复回调。我启用了手动提交。如何在恢复回调方法中确认消息，以便没有延迟。

    @Bean
    public ConcurrentKafkaListenerContainerFactory<String, Map<String, Object>> kafkaListenerContainerFactory() {
        ConcurrentKafkaListenerContainerFactory<String, Map<String, Object>> factory = new ConcurrentKafkaListenerContainerFactory<>();
        factory.setConcurrency(conncurrency);
        factory.setConsumerFactory(consumerFactory());
        factory.setRetryTemplate(retryTemplate());
                factory.setRecoveryCallback(new RecoveryCallback<Object>() {
        @Override
        public Object recover(RetryContext context) throws Exception {
            // TODO Auto-generated method stub
            logger.debug(" In recovery callback method !!");
            return null;
        }
    });
        factory.getContainerProperties().setAckMode(AckMode.MANUAL);
        return factory;
    }

    /*
     * Retry template.
     */

    protected RetryPolicy retryPolicy() {
        SimpleRetryPolicy policy = new SimpleRetryPolicy(maxRetryAttempts, retryableExceptions);
        return policy;
    }

    protected BackOffPolicy backOffPolicy() {
        ExponentialBackOffPolicy policy = new ExponentialBackOffPolicy();
        policy.setInitialInterval(initialRetryInterval);
        policy.setMultiplier(retryMultiplier);
        return policy;
    }

    protected RetryTemplate retryTemplate() {
       RetryTemplate template = new RetryTemplate();
       template.setRetryPolicy(retryPolicy());
       template.setBackOffPolicy(backOffPolicy());
       return template;
    }
}

Answer 1

你的问题太宽泛了。你需要更加具体。

在框架中没有任何假设，如果在消费错误期间重试耗尽，您可以做些什么。

我认为你应该从Spring Retry项目开始，了解RecoveryCallback到底是什么以及它是如何运作的：

如果在模板决定中止之前业务逻辑没有成功，那么客户端有机会通过恢复回调进行一些备用处理。

RetryContext有：

/**
 * Accessor for the exception object that caused the current retry.
 * 
 * @return the last exception that caused a retry, or possibly null. It will be null
 * if this is the first attempt, but also if the enclosing policy decides not to
 * provide it (e.g. because of concerns about memory usage).
 */
Throwable getLastThrowable();

Spring Kafka还为RetryContext RecoveryCallback中的RetryContext填充其他属性：https://docs.spring.io/spring-kafka/docs/2.0.0.RELEASE/reference/html/_reference.html#_retrying_deliveries

传递给RecoveryCallback的{{1}}的内容取决于监听器的类型。上下文将始终具有属性record，该属性是发生故障的记录。如果您的听众正在确认和/或消费者，则可以使用其他属性acknowledgment和/或consumer。为方便起见，RetryingAcknowledgingMessageListenerAdapter为这些键提供了静态常量。有关更多信息，请参阅其javadoc。

Spring Kafka使用者 - 具有恢复回调机制的手动提交

1 个答案: