kafkaコンシューマーでロジックを再試行します
キューから特定のログを消費し、そのログからの情報でサードパーティのAPIにアクセスするユースケースがあります。サードパーティのシステムが適切に応答しない場合は、その特定のログに再試行ロジックを実装したいと思います。
時間フィールドを追加して同じキューにメッセージを再プッシュできます。時間フィールドが有効な場合、つまり現在の時間よりも短い場合、このメッセージは再び消費され、そうでない場合は再びキューにプッシュされます。
ただし、このロジックは、再試行時間が正しくなり、キューが不必要に大きくなるまで、同じログを何度も追加します。
Kafkaに再試行ロジックを実装するより良い方法はありますか？
複数の再試行トピックを作成して、失敗したタスクをそこにプッシュできます。たとえば、分単位の遅延が異なる3つのトピックを作成し、失敗した1つのタスクを最大試行制限に達するまでローテーションできます。
‘retry_5m_topic’ —5分で再試行します
‘retry_30m_topic’ —30分で再試行します
‘retry_1h_topic’ —1時間で再試行します
詳細については、以下を参照してください： https://blog.pragmatists.com/retrying-consumer-architecture-in-the-Apache-kafka-939ac4cb851a
はい、これは私も考えた1つのまっすぐな解決策かもしれません。しかし、これにより、メッセージ処理が再び失敗する可能性があるため、多くのトピックを作成することになります。
このユースケースをRabbitMQにマッピングすることで、この問題を解決しました。ウサギMQには、メッセージ処理が交換から失敗した場合にTTLを使用して再試行交換に送信できる再試行交換の概念があります。 TTLの有効期限が切れると、メッセージはメインエクスチェンジに戻り、再度処理できるようになります。
RabbitMQを使用して指数バックオフメッセージ処理を実装する方法を説明するいくつかの例を投稿できます。
コンシューマーでは、例外をスローした場合、試行番号1の別のメッセージを生成します。したがって、次に消費されたときに、試行番号1のプロパティがあります。プロデューサーで処理し、再試行回数を超えて試行した場合は、その後、それを生成するのをやめます。