問題タブ [dead-letter]

spring-kafka 2.1.x を使用して Spring Boot 2.0 アプリケーションでデッド レター キュー (DLQ)の概念を実装し、Bean の@KafkaListenerメソッドによって処理できなかったすべてのメッセージを事前定義された Kafka DLQ トピックに送信する最良の方法は何ですか?単一のメッセージを失うことはありませんか？

したがって、消費された Kafka レコードは次のいずれかです。

1. 正常に処理され、
2. 処理に失敗し、DLQ トピックに送信されます。
3. 処理に失敗し、(予期しない問題により) DLQ トピックに送信されないため、リスナーによって再び消費されます。

KafkaTemplate を使用して DLQ トピックへの処理に失敗したレコードを送信するErrorHandlerのカスタム実装でリスナー コンテナーを作成しようとしました。無効化された自動コミットとRECORD AckMode の使用。

この実装は項目#3を保証していないようです。DlqErrorHandler で例外がスローされた場合、レコードはリスナーによって再び消費されません。

トランザクション リスナー コンテナーの使用は役に立ちますか?

Spring Kafka を使用して DLQ の概念を実装する便利な方法はありますか?

2018/03/28更新

Gary Russell の回答のおかげで、次のように DlqErrorHandler を実装することで、目的の動作を実現できました。

この方法では、コンシューマー ポーリングが 3 つのレコード (1、2、3) を返し、2 番目のレコードを処理できない場合:

• 1が処理されます
• 2 は処理に失敗し、DLQ に送信されます
• 3 コンシューマーが record.offset() + 1 をシークしたおかげで、リスナーに配信されます

DLQ への送信が失敗した場合、消費者は record.offset() をシークし、レコードはリスナーに再配信されます (DLQ への送信はおそらく廃止されます)。

2021/04/30更新

Spring Kafka 2.7.0 以降、ノンブロッキングの再試行と配信不能トピックがネイティブでサポートされています。

例を参照してください: https://github.com/evgeniy-khist/spring-kafka-non-blocking-retries-and-dlt

通常、再試行はノンブロッキング (別のトピックで行う) で、遅延させる必要があります。

• リアルタイムのトラフィックを中断しないため。
• 呼び出しの数を増幅させず、本質的に不正なリクエストをスパム送信します。
• 可観測性のため (再試行回数とその他のメタデータを取得するため)。通常、Kafka でノンブロッキングの再試行と DLT 機能を実現するには、追加のトピックを設定し、対応するリスナーを作成して構成する必要があります。

そこで、SQS を使用する小さなアプリケーションを構築しています。特定のメッセージが処理済みと見なされるか、再試行用にマークされているか (再キューイングされる)、または処理できないか (デッドレターに送信する必要があるか) を判断する単純なハンドラープロセスがあります。

ただし、ドキュメントに基づいて、本当に DL にメッセージを送信する唯一の方法は、メッセージがラックアップされた受信数に対して動作するリドライブ ポリシーを使用することです。私のアプリケーションの性質上、プロセスが特定のメッセージを処理する準備ができていない場合、有効な再試行を数回行うことができますが、受信したばかりのメッセージを DL したい場合もあります。AWS/Boto3 は特定のメッセージを DL にマークする方法を提供していませんか?

自分の DL と見なす別のキューに自分でメッセージを送信できることはわかっています。これには、AWS の組み込みツールを使用することをお勧めします。

バックアウト キューが QB で、バックアウトしきい値が 3 のキュー Q1 があります。有害メッセージを処理するさまざまな可能性に取り組んでいるため、キューからメッセージを読み取り、キューをポーリングし続けるたびに、アプリケーションが例外をスローするようにしました。Q1 の深さは 15、QB は 5、DLQ は 5 です。最初のシナリオでは、Q1 に 7 つのメッセージを入力し、アプリケーションを起動しました。予想どおり、各メッセージはキューにロールバックされ、バックアウト カウントが 3 のときにバックアウト キューに移動されました。魅力的に動作します。

バックアウト キューと DLQ の両方がいっぱいになったときに何が起こるかを知る必要がある 2 番目のシナリオでは、12 のメッセージを入力してアプリケーションを開始しました。次に、DLQ is full をスローしますが、これは明らかです。

しかし、MQ エクスプローラーで観察できるのは、12 個のメッセージが Q1、QB、および DLQ の間で無限にループし続けることです。私自身がアプリケーションを停止すると、アプリケーションを開始する前と同様に、すべてのメッセージが Q1 で終了します。

完全に混乱し、グーグルで検索しましたが、これに似たものは何も見つかりませんでした。

私が間違っていることや、このパズルに欠けているピースを誰か指摘できますか?

前もって感謝します。