マイクロサービスアーキテクチャ設計パターン-(8) SAGA

saga (メッセージ主導型のローカル トランザクションのシーケンス)

2PC

• 参考：https://zhuanlan.zhihu.com/p/35616810
  • コーディネーターは参加者に正常に実行できるかどうかを尋ねます
    • 参加者はトランザクションを実行しますがコミットしません
  • コーディネーターは結果に基づいて通知 (コミットまたはロールバック) を開始します。
• 欠点がある
  • 同期ブロッキング
    • トランザクションのこのフェーズ中、リソースはロックされます。
  • 単一障害点
    • コーディネーターが失敗し、参加者がブロックされました
      • 特にセカンドステージでは皆さんからのメッセージをお待ちしております。
  • データに一貫性がありません
    • 参加者が 2 番目のステップで通知を受信しない場合、データは不整合になります。
  • 解決できない問題
    • 第 2 段階では、コミットの発行後にコーディネーターがダウンし、コミットを受信した唯一のマシンがダウンします。その場合、このトランザクションがどのように実行されるかは誰も知りません。

3PC

• ステップ
  • コミットできる
    • コーディネーターは実行できるかどうか尋ねます
  • プレコミット
    • コーディネーターが事前実行を送信
  • コミットしてください
    • コーディネーターはコミットまたは割り込みを送信します
• 2PCとの違い
  • フェーズ 3 で参加者がメッセージを受信しない場合は、タイムアウト後に送信します。
  • コミットでき、リソースをロックせず、リソースの浪費の可能性を削減します。

佐賀

• トランザクションの実行は複数のサービスに分散されます
• シリアル実行
  • 3つの部分
    • 賠償事項
      • トランザクションが失敗した後はロールバックする必要がありますが、トランザクションはすでにコミットされているため、後続のタスクが失敗したときに補償する必要があります。
        • 補正方法の 1 つ: たとえば、注文を作成するときに、注文のステータスを示すステータスを設定します。作成プロセス中に、新しい注文が作成ステータスで挿入されましたが、その後の検証に失敗しました。補償アクションとして、ステータスを拒否に設定します。
          • この状態はセマンティック ロックと呼ばれます。送信済みであるが変更される可能性があることを示します
          • もちろん、トランザクションの終了時にはステータスを承認に変更する必要があります。
    • 重要事項
      • 失敗できないトランザクションが続く
        • これが成功すると、後続のトランザクションも成功する必要があります。
    • 反復可能なトランザクション
      • 常に成功します。成功しない場合は成功するまで再試行してください
        • たとえば、注文ステータスを承認に変更します。フィールドの値を変更するだけですか?

協力的な物語

• サーガのロジックと実行シーケンスは、参加しているサービスに書き込まれます。
  • 実行順序がA→B→Cの場合
    • A が正常に実行された後、メッセージをパブリッシュします。
    • B は A からのメッセージを受信し、実行します
    • C は B からのメッセージを受信し、実行します
• 利点
  • 単純
• 質問
  • 循環依存関係がある可能性があります
  • むしろ理解するのが難しい
    • このトランザクションにどのサービスが関与しているかを確認するのは困難です
  • 密結合のリスク
    • B によって実行されるトランザクションは多くのイベントの影響を受ける可能性があるため、A の複数のメッセージ イベントに注意を払う必要があります。

振付された物語

• 参加者に何をすべきかを指示するオーケストレーター クラスがあります。
• オーケストレーター モデリングへの優れたアプローチ
  • ステートマシン
    • イベントによってトリガーされる一連の状態と一連の状態遷移
• 利点
  • 単純な依存関係
    • 循環依存関係を導入しない
    • オーケストレーターに依存するパーティ
    • 参加者はオーケストレーターに依存しない
  • カップリングが少ない
    • 参加者はサービス API を提供するだけであり、公開されたイベントには関心がありません。
      • サービスを提供していますので、利用したい場合は電話してください。あなたの状況は気にしません（投稿されたイベント）
  • 懸念事項を分離し、ビジネス ロジックを簡素化する
    • 参加者は自分のビジネスに関連することのみを行う必要があります
    • オーケストレーターは状態遷移についてのみ考慮する必要があります。
• 短所
  • オーケストレーターにはビジネス ロジックが多すぎる可能性があります
• 質問
  • saga の実行中にデータの読み取り/変更が行われると、データの不整合が露呈する可能性があります。
    • トランザクションの分離の問題です
    • 解決
      • セマンティックロック
        • たとえば、注文の作成ステータス
      • 実行順序を合理的に調整する
      • 値を再読み込み
        • 機能: アップデートの紛失を防ぐ
        • 方法: 更新する前にデータを読み取り、変更が加えられているかどうかを確認します。
          • メインライブラリを読む