RERRYTEMPLATE与ErrorHandler的性能比较

Question

我有两种方法可以通过

1. 在kafkalistener中使用retryTemplate从kafkalistener错误恢复，方法：

@KafkaListener(topics: "topic1")
public void handle(command) {
    retryTemplate.execute(ctx -> {
        processCommand(command);
    });
    // Retries exhausted, execute the recoverer logic
    recover(command);
}

2. 将errorHandler设置为MessageListenerContainer通过contagererCustomizer：

@Component
    public class ContainerCustomizer {
        public ContainerCustomizer(CustomConcurrentContainerListenerFactory factory) {
            factory.setContainerCustomizer(container -> {
                    container.setErrorHandler(new SeekToCurrentErrorHandler((ConsumerRecord<?, ?> record, Exception e) -> {
                        //logic for recoverer after retries exhausted
                        recover(convertRecord(record));
                    }, new ExponentialBackOffWithMaxRetries(2)));
            });
        }
    }

在性能上：涉及性能和阻止消费者线程时，这两个选项如何比较这两个选项？确实说，使用retrytemplate.execute，在单独的线程中处理重试时，带有containerListener.seterlistener.seterrorhandler它会阻止主要消费者的线程？

Answer 1

两者都会阻塞消费者线程——否则你将继续处理记录，并且 Kafka 的排序保证将会丢失。

此外，这两种方法均已弃用，取而代之的是 DefaultErrorHandler，它是 SeekToCurrentErrorHandler 的演变。

两者之间的区别在于，使用 Spring Retry 时，所有调用都将在内存中重试，因此您应该确保聚合退避不会超过 max.poll.interval.ms< /code> 否则代理会认为您的服务器已失效并将执行重新平衡。

SeekToCurrentErrorHandler 以及 DefaultErrorHandler 都会在每次重试时向代理执行新的查找，因此您只需确保最大延迟加上执行时间不超过 <代码>max.poll.interval.ms。

如果您需要非阻塞重试，请查看非阻塞重试功能。