問題タブ [two-phase-commit]

バックグラウンド：

データベースを更新するパイプラインに沿った複数のソース、複数のシンク、および複数のオペレーターで構成される Flink パイプラインがあります。

質問のために、そして簡単にするために、次のようなパイプラインがあると仮定しましょう。

このパイプラインにより、一部のデータの変更に関する通知をリッスンできるはずです。(各通知には ID が含まれます) 通知ごとに、DB からデータを読み取り、アルゴリズムを実行して、同じ DB 行を更新します。その後、データの変化の大きさも出力します。データ変更の大きさが十分に大きい場合にのみ、別の Kafka トピックに通知を送信します。

• Source は Kafka トピックにサブスクライブして、変更されたデータ ID に関する通知をリッスンします。
• KeyBy は ID によってキーイングされ、同じ ID がオペレーターの 2 つのインスタンスによって同時に処理されないようにします。
• ID を指定すると、FlatMap は DB からデータを読み取り、アルゴリズムを実行して、同じ DB 行を更新します。変化の大きさを発します。これは Map ではなく FlatMap です。これは、特定のエラーが発生した場合など、変更の大きさを発行したくない場合があるためです。
• Filter は、ある閾値よりも小さいマグニチュードでストリームをフィルタリングします
• シンクは、フィルタリングされた通知を別の Kafka トピックに送信しています。

質問：

1 回限りのセマンティクスでパイプラインを実行したいと考えています。私たちが見たところ、Flink は、Kafka ソース、Kafka シンク、および中間のステートフルまたはステートレス オペレーターに対して、1 回限りのセマンティクスをサポートしています。パイプラインに沿って更新するリソースを 1 回だけ実行する方法を説明している場所が見つかりませんでした。1 回限りのセマンティクスを許可するシンク関数を作成できるTwoPhaseCommitSinkFunctionがあります。

データベースを更新した後、Kafka に変更通知を発行するため、使用できません。2 つの別々のシンクで実行すると、DB が実際に更新される前にマグニチュード通知を受信できる競合状態が発生します。

何か不足していますか？Map/FlatMap オペレーターで 2 フェーズ コミットを実装する方法はありますか? 別の解決策はありますか？

ありがとう！

2PC は安全である、つまり、トランザクションをコミットするか、ロールバックするかのどちらかであるという多くの読みを見つけました。より具体的には、[コミットした場合、誰も中止しません。1 つが中止された場合、誰もコミットしません]。( http://www0.cs.ucl.ac.uk/staff/B.Karp/gz03/f2010/gz03-lecture6-2PC.pdf )

ウィキペディアから、私はコミット段階で、すべてのプロセスが次のことを行うことを知っています:

1. コーディネーターはすべての参加者にコミット メッセージを送信します。
2. 各参加者は操作を完了し、トランザクション中に保持されていたすべてのロックとリソースを解放します。
3. 各参加者は、確認をコーディネーターに送信します。
4. コーディネーターは、すべての確認応答が受信されるとトランザクションを完了します。

ステージ 1 では、コーディネーターが複数の参加者にメッセージを送信した後に失敗するのではないかと思います。つまり、一部の参加者はコミット メッセージを受信し、他の参加者は受信しません。その後、受け取った人はコミットしますが、他の人はまだブロックされます. では、ここで 2PC は安全性を確保していないと思いますか?

マイクロサービス アーキテクチャを研究しています。3つのアプローチがあることを理解しています：

1. 2 フェーズ コミット

2. 佐賀

3. 結果整合性

2 フェーズ コミット アプローチとサガ アプローチについて質問があります。

2 フェーズ コミットには、トランザクション マネージャーがあります。サガ アプローチと同様に、サガ ログとサガ SEC があります。どちらの方法でも、中央システムに責任を負わせています。では、正確には何が違いますか。

認証とメインのアプリケーション サービスという 2 つのマイクロサービスを含む Asp.Net Core でシステムを開発しています。

質問があります: ユーザーが作成している間、Saga パターンを使用して分散トランザクションを管理する必要がありますか、それとも 2 フェーズ コミットを使用できますか? この場合はどうすればよいでしょうか (両方のマイクロサービスでユーザーを作成する必要があります)。ユーザーが作成したときにクライアントメッセージに送信しますか?

Redis がレプリケーションを処理する方法を理解しようとしています。documentationによると、Redisには1つのマスターとn個のスレーブがあり、それ自体もn個のスレーブを持つことができます。私が理解している限り、これはツリーのような構造になります。マスターは、更新を承認するスレーブを非同期的に更新します。しかし、私はどのプロトコルが使用されているのだろうかと思っています。Redisには明示的な準備フェーズがないことを読んでいなかったため、2フェーズは使用されていないため、1フェーズコミットのように理解しました。

私はそれを正しく理解しましたか？ありがとうございました。

(さらに有用なリソースがある場合は、それについて詳しく教えていただければ幸いです。これまでのところ、使用されているプロトコルに関する明示的なドキュメントは見つかりませんでした)

2つの違いは何ですか？表面上のプロトコルは異なっているように見えますが、両者の実際の違いと、それらが同等ではない理由を理解したいと思います。