死信主題分割槽選擇

預設情況下，記錄被髮布到死信主題時使用與原始記錄相同的分割槽。這意味著死信主題必須至少擁有與原始記錄相同數量的分割槽。

要改變這種行為，可以將一個 DlqPartitionFunction 實現作為 @Bean 新增到應用上下文中。應用中只能存在一個這樣的 Bean。該函式會接收消費者組、失敗的 ConsumerRecord 和異常作為引數。例如，如果您總是想路由到分割槽 0，可以使用

@Bean
public DlqPartitionFunction partitionFunction() {
    return (group, record, ex) -> 0;
}

如果您將消費者繫結的 dlqPartitions 屬性設定為 1（並且 binder 的 minPartitionCount 等於 1），則無需提供 DlqPartitionFunction；框架將始終使用分割槽 0。如果您將消費者繫結的 dlqPartitions 屬性設定為大於 1 的值（或 binder 的 minPartitionCount 大於 1），則**必須**提供一個 DlqPartitionFunction bean，即使分割槽數量與原始主題的分割槽數量相同。

也可以為 DLQ 主題定義自定義名稱。為此，可以在應用上下文中建立一個 DlqDestinationResolver 實現作為 @Bean。當 binder 檢測到這樣的 bean 時，它將優先使用，否則將使用 dlqName 屬性。如果兩者都未找到，則預設使用 error.<destination>.<group>。以下是 DlqDestinationResolver 作為 @Bean 的示例。

@Bean
public DlqDestinationResolver dlqDestinationResolver() {
    return (rec, ex) -> {
        if (rec.topic().equals("word1")) {
            return "topic1-dlq";
        }
        else {
            return "topic2-dlq";
        }
    };
}

在提供 DlqDestinationResolver 實現時需要記住一件重要的事情，那就是 binder 中的 provisioner 不會自動為應用建立主題。這是因為 binder 無法推斷出該實現可能傳送到的所有 DLQ 主題的名稱。因此，如果您使用這種策略提供 DLQ 名稱，則應用有責任確保這些主題事先被建立。