死信主题处理

启用 DLQ

要启用 DLQ，基于 Kafka Binder 的应用必须通过属性 spring.cloud.stream.bindings.<binding-name>.group 提供一个消费者组。匿名消费者组（即应用未显式提供组的情况）无法启用 DLQ 功能。

当应用希望将出错的记录发送到 DLQ 主题时，该应用必须启用 DLQ 功能，因为默认情况下此功能未启用。要启用 DLQ，必须将属性 spring.cloud.stream.kafka.bindings.<binding-name>.consumer.enable-dlq 设置为 true。

启用 DLQ 后，在处理发生错误并且根据 spring.cloud.stream.bindings.<binding-name>.consumer.max-attempts 属性耗尽所有重试次数后，该记录将被发送到 DLQ 主题。

默认情况下，max-attempts 属性设置为三。当 max-attempts 属性大于 1 且 DLQ 已启用时，您将看到重试遵循 max-attempts 属性的设置。如果未启用 DLQ（这是默认设置），则 max-attempts 属性对重试的处理方式没有任何影响。在这种情况下，重试将回退到 Spring for Apache Kafka 中容器的默认设置，即重试 10 次。如果应用希望在 DLQ 被禁用时完全禁用重试，则将 max-attempts 属性设置为 1 将不起作用。在这种情况下，要完全禁用重试，您需要提供一个 ListenerContainerCustomizer 并使用适当的 Backoff 设置。以下是一个示例。

@Bean
ListenerContainerCustomizer<AbstractMessageListenerContainer<?, ?>> customizer() {
	return (container, destinationName, group) -> {
		var commonErrorHandler = new DefaultErrorHandler(new FixedBackOff(0L, 0l));
		container.setCommonErrorHandler(commonErrorHandler);
	};
}

通过这种方式，将禁用默认的容器行为，并且不会尝试任何重试。如上所述，启用 DLQ 时，Binder 设置将具有优先权。

处理死信主题中的记录

由于框架无法预测用户希望如何处理进入死信队列的消息，因此它不提供任何标准机制来处理它们。如果死信的原因是暂时的，您可能希望将消息路由回原始主题。然而，如果问题是永久性的，可能会导致无限循环。本主题中的示例 Spring Boot 应用展示了如何将这些消息路由回原始主题，但在三次尝试后，它会将它们移至一个“停放”主题。该应用是另一个 Spring Cloud Stream 应用，它从死信主题读取。当连续 5 秒未收到消息时，它会退出。

示例假设原始目标主题是 so8400out，消费者组是 so8400。

有几种策略可供考虑

考虑仅在主应用未运行时运行重新路由。否则，临时错误的重试次数会非常快地耗尽。
或者，使用两阶段方法：使用此应用将消息路由到第三个主题，再使用另一个应用从该主题路由回主主题。

以下代码清单展示了示例应用

application.properties

spring.cloud.stream.bindings.input.group=so8400replay
spring.cloud.stream.bindings.input.destination=error.so8400out.so8400

spring.cloud.stream.bindings.output.destination=so8400out

spring.cloud.stream.bindings.parkingLot.destination=so8400in.parkingLot

spring.cloud.stream.kafka.binder.configuration.auto.offset.reset=earliest

spring.cloud.stream.kafka.binder.headers=x-retries

应用

@SpringBootApplication
public class ReRouteDlqKApplication implements CommandLineRunner {

    private static final String X_RETRIES_HEADER = "x-retries";

    public static void main(String[] args) {
        SpringApplication.run(ReRouteDlqKApplication.class, args).close();
    }

    private final AtomicInteger processed = new AtomicInteger();

    @Autowired
    private StreamBridge streamBridge;

    @Bean
    public Function<Message<?>, Message<?>> reRoute() {
        return failed -> {
            processed.incrementAndGet();
            Integer retries = failed.getHeaders().get(X_RETRIES_HEADER, Integer.class);
            if (retries == null) {
                System.out.println("First retry for " + failed);
                return MessageBuilder.fromMessage(failed)
                        .setHeader(X_RETRIES_HEADER, 1)
                        .setHeader(BinderHeaders.PARTITION_OVERRIDE,
                                failed.getHeaders().get(KafkaHeaders.RECEIVED_PARTITION_ID))
                        .build();
            }
            else if (retries < 3) {
                System.out.println("Another retry for " + failed);
                return MessageBuilder.fromMessage(failed)
                        .setHeader(X_RETRIES_HEADER, retries + 1)
                        .setHeader(BinderHeaders.PARTITION_OVERRIDE,
                                failed.getHeaders().get(KafkaHeaders.RECEIVED_PARTITION_ID))
                        .build();
            }
            else {
                System.out.println("Retries exhausted for " + failed);
                streamBridge.send("parkingLot", MessageBuilder.fromMessage(failed)
                    .setHeader(BinderHeaders.PARTITION_OVERRIDE,
                            failed.getHeaders().get(KafkaHeaders.RECEIVED_PARTITION_ID))
                    .build());
            }
            return null;
        };
    }

    @Override
    public void run(String... args) throws Exception {
        while (true) {
            int count = this.processed.get();
            Thread.sleep(5000);
            if (count == this.processed.get()) {
                System.out.println("Idle, exiting");
                return;
            }
        }
    }
}