問題タブ [exactly-once]

Stream Processing アプリケーション (Apache Flink または Apache Spark Streaming に基づく) では、データを一度だけ処理する必要がある場合があります。

データベースの世界では、ACID 基準に従うデータベースを使用することで同等のことが達成されます (ここで間違っている場合は訂正してください)。

ただし、ACID ではなく BASE に従っている (非リレーショナル) データベースは多数あります。

ここで私の質問は次のとおりです。このような BASE データベースをストリーム処理アプリケーションに統合する場合 (正確に 1 回)、パイプライン全体で正確に 1 回の処理を保証できますか? また、これが可能である場合、どのような状況で可能ですか?

JVM 用の Lettuce Redis クライアントを使用して、Redis リストに基づくキューを構築しています。メモリ内キューのように動作するのが理想的ですが、ネットワークの相互作用が関係しているため、これは不可能です。

レタスのドキュメントにはエラー処理に関するセクションがあり、私の場合、エラーが発生したときに失敗したコマンドを再試行したいと考えています。問題は、例外階層があまり細かく設定されておらず、次の問題に対処する方法がわからないことです。

• 失敗したコマンドを再試行できるかどうかを判断する方法は? コマンドが無期限に失敗し、再試行が無限ループにつながる理由はいくつかあります。現在の Redis バージョンは使用されているコマンド構文をサポートしていない、キーが既に存在し、互換性のないタイプであるなどです。
• 信頼できないネットワークの場合に、レタスに常に再接続するように頼ることはできますか? RedisException場合によっては、一部を再試行したりNativeIoException、Redis クライアント インスタンスを再作成したり、アプリケーション全体を再起動したりするべきではない可能性はありますか?
• 失敗したコマンドが実際に Redis によって実行されたものではなく、再試行しても重複やデータの損失が発生しないかどうかを知る方法はありますか (または、少なくともこれは、場合によっては例外クラスによって決定される可能性があります)。これは、1 回限りの配信の基本的な問題である可能性があります。私の知る限り、Redis はこれに対処する手段を提供していません (たとえば、Kafka とは異なります)。

この問題は誰もが対処しなければならないように見えますが、これに関する情報はあまりないようです。

冪等性とはログで「各メッセージが一度書き込まれる」ことを意味することを理解したと思いますが、EOS (Exactly-Once Delivery Semantic)について話すと、消費者も役割を果たし、エンド ツー エンドの保証に入ります。

したがって、ここ(たとえば) で述べたように、冪等性とトランザクションの両方が必要であり、「エンド ツー エンドで 1 回限りのセマンティクス」には十分です。

ただし、圧縮に関する Kafka docは次のように述べています。

データはブローカに圧縮形式で格納されるため、有効なフェッチ オフセットは圧縮されたメッセージ境界です。したがって、圧縮データの場合、消費されるオフセットは一度に 1 つの圧縮メッセージずつ進められます。これには、コンシューマに障害が発生した場合に重複が発生する可能性があるという副作用があります。

質問：

• プロデューサーが冪等であり、コンシューマーが Kafka (Kafka Streams など) 内でトランザクションである場合でも、オフセットが圧縮されたメッセージ境界で進められるため、重複が表示されることがあります。圧縮されたメッセージの境界ではない単一のメッセージを処理することを検討してください。オフセットは進められていないため、コンシューマーが失敗すると重複が表示されます。正しい？

圧縮を有効にすると、EOS の取り組みが無効になる可能性があるようです。EOS について議論している記事では、これについて言及されていません。