パターンの仕組み

メッセージ処理が失敗した場合、メッセージはバックオフタイムスタンプで再試行トピックに転送されます。次に、再試行トピックコンシューマーはタイムスタンプをチェックし、期限が到来していない場合は、そのトピックのパーティションの消費を一時停止します。期限が来ると、パーティションの消費が再開され、メッセージが再び消費されます。メッセージ処理が再び失敗した場合、メッセージは次の再試行トピックに転送され、処理が成功するか、試行回数が尽きるまでパターンが繰り返され、メッセージはデッドレタートピック (構成されている場合) に送信されます。

たとえば、"main-topic " トピックがあり、1000ms の指数関数的バックオフ、乗数 2、最大試行回数 4 回のノンブロッキング再試行を設定したい場合、main-topic-retry-1000、main-topic-retry-2000、main-topic-retry-4000、main-topic-dlt トピックを作成し、それぞれのコンシューマーを設定します。フレームワークはまた、トピックの作成、リスナーの設定と構成も行います。

この戦略を使用すると、そのトピックに対する Kafka の順序の保証が失われます。

好みの AckMode モードを設定できますが、RECORD が推奨されます。

現時点では、この機能はクラスレベルの @KafkaListener アノテーションをサポートしていません。

asyncAcks を true に設定して手動 AckMode を使用する場合、DefaultErrorHandler は seekAfterError を false に設定して構成する必要があります。バージョン 2.9.10、3.0.8 以降、このような構成ではこれが無条件に true に設定されます。以前のバージョンでは、RetryConfigurationSupport.configureCustomizers() メソッドをオーバーライドしてプロパティを true に設定する必要がありました。

@Override
protected void configureCustomizers(CustomizersConfigurer customizersConfigurer) {
    customizersConfigurer.customizeErrorHandler(eh -> eh.setSeekAfterError(false));
}

さらに、これらのバージョンより前は、asyncAcks プロパティに関係なく、デフォルト (ロギング) DLT ハンドラーの使用は、いかなる種類の手動 AckMode とも互換性がありませんでした。