分散トランザクション知識の要約

[[426542]]

1. トランザクションのACID

• アトミック性とは、トランザクション内のすべての操作が実行される、または実行されない、という意味です。

• 一貫性は、データが整合性制約を満たすこと、つまりデータの中間状態が存在しないことを意味します。たとえば、あなたの口座に 400 元があり、私の口座に 100 元があり、あなたが私に 200 元を送金した場合、あなたの口座のお金は 200 元になり、私の口座のお金は 300 元になります。私の口座のお金は増えているのに、あなたの口座のお金は減っていないという中間状態は発生しません。

• 分離とは、複数のトランザクションが同時に実行されたときに互いに干渉しないことを意味します。つまり、トランザクション内のデータは他のトランザクションから分離されます。

• 耐久性とは、トランザクションが完了した後、データが永久に保存され、その後の他の操作や障害がトランザクションの結果に影響を与えないことを意味します。

2. Redisトランザクション

• Redis トランザクションでは、すべての操作が実行される、または実行されないことを保証することはできません。

• Redis トランザクション内のコマンドが失敗した場合でも、後続のコマンドは引き続き処理され、Redis はコマンドを停止しないため、ロールバックされません。

• Redis では、コマンド エラーが構文エラーによるものである場合、開発中に検出され、実稼働環境では発生しないはずだと考えています。ロールバックはプログラミング エラーの影響を受けません。

3. 2PC

• 一貫性のあるデザインです

• 各参加者 (各ローカル リソースとも呼ばれます) の送信とロールバックを調整および管理するためのトランザクション コーディネーター ロールを導入します。 2 つの段階とは、準備 (投票) 段階と提出段階を指します。

• 通常の状況

  • 準備フェーズ: コーディネーターは各参加者に準備コマンドを送信します。これは、トランザクションの送信を除くすべての作業が完了したことを意味します。すべてのリソースからの応答が送信フェーズに入るまで同期的に待機します。
  • コミット フェーズ: コーディネーターは、すべての参加者にトランザクションのコミット コマンド (トランザクションをコミットするか、トランザクションをロールバックする) を送信し、すべてのトランザクションが正常にコミットされるまで待機してから、トランザクション実行の成功を返します。

• 異常事態

  • 準備フェーズ中に参加者が失敗を返した場合、コーディネーターはすべての参加者にトランザクションをロールバックする要求を送信し、分散トランザクションが失敗したことを示します。
  • 2 番目のフェーズではロールバック トランザクション操作が実行されるため、すべての参加者がロールバックするまで再試行を続けることが答えです。そうしないと、最初のフェーズで正常に準備された参加者がブロックされます。
  • 2 番目の段階はトランザクション操作を送信することです。一部の参加者のトランザクションが正常に送信されている可能性があるため、答えは再試行を続けることです。現時点では、急いで前進し、送信が成功するまで再試行し続けるという唯一の方法があります。結局、本当に機能しない場合は、手動による介入が必要になります。

• コーディネータ障害分析

  • 2PCは同期ブロッキングプロトコルである
  • コーディネータにはタイムアウトメカニズムがある
  • コーディネーターは単一のポイントであるため、単一障害点となります。
    • 準備コマンドを送信する前にコーディネータがクラッシュしたため、トランザクションが開始されませんでした。影響なし
    • 準備コマンドの送信後にコーディネータがクラッシュし、トランザクション リソースがロックされます。トランザクションを実行できず、他の操作がブロックされます。
    • ロールバック トランザクション コマンドを送信する前にコーディネータがクラッシュします。トランザクションをコミットできません。最初のフェーズで正常に準備した参加者全員がブロックされます。
    • ロールバック トランザクション コマンドを送信した後にコーディネータがハングした場合、ロールバックは成功する可能性が高く、すべてのリソースが解放されます。ただし、ネットワークパーティションが発生すると、一部の参加者はコマンドを受信できずにブロックされます。
    • コミットトランザクションコマンドを送信する前にコーディネータがクラッシュし、すべてのリソースがブロックされました。
    • コーディネーターがトランザクションコミット コマンドを送信した後に切断した場合、トランザクションは正常にロールバックされ、リソースが解放される可能性が高くなります。ただし、ネットワークパーティションが発生すると、一部の参加者はコマンドを受信できずにブロックされます。

• 新しいコーディネーターを選出する

  • 各参加者のステータスはコーディネータと参加者自身のみが知っているため、新しいコーディネータは、出席している参加者のステータスから失敗した参加者のステータスを推測することはできません。
  • 極端な場合にはデータの不整合は避けられない

• 要約する

  • 同期ブロッキング、分散トランザクションの強力な一貫性を確保する
  • 一般的に、効率は低く、単一障害点の問題があり、極端な状況ではデータの不整合が発生する可能性があります。
  • データの一貫性は達成できず、補償メカニズムが必要である

4. 3PC

• 参加者にはタイムアウトメカニズムも導入されている
• CanCommit、PreCommit、および DoCommit
• 通常の状況
  • 準備段階: 参加者の状態と負荷について尋ねる
  • 提出前段階: 2PC準備段階と同じ
  • 提出フェーズ: 2PC提出フェーズと同じ

• 利点
  • リソースを直接ロックするのではなく、まず状況を問い合わせます
  • タイムアウトメカニズムを追加する
    • コミット前コマンドの待機がタイムアウトした場合は、必要な操作を実行してください。
    • コミット コマンドの待機がタイムアウトすると、参加者はトランザクションをコミットします。
• デメリット
  • もう1ステージ追加するとパフォーマンスは悪くなりますが、ほとんどの場合リソースは利用可能です
  • タイムアウトメカニズムには依然としてデータの不整合がある
  • たとえば、コミット コマンドの待機中にタイムアウトが発生した場合、参加者はデフォルトでコミット トランザクション操作を実行しますが、ロールバック操作を実行する可能性があり、データの不整合が発生します。
• 要約する
  • 参加者間の状態を統一するために、事前コミット フェーズが導入されます。スケジューラが失敗した場合、新しいコーディネータが来て、参加者が事前送信または送信段階にあることがわかった場合、それはすべての参加者によって確認されたことを意味するため、この時点で送信コマンドが実行されます。
  • 参加者のタイムアウト メカニズムが導入されましたが、全体的な対話プロセスが長くなり、パフォーマンスが低下し、データの不整合の問題が依然として存在していました。一時停止された参加者がトランザクションを実行したかどうかを判断することは不可能であるためです。補償メカニズムが必要

5. TCC

• TCC

  • Try は予約、つまりリソー​​スの予約とロックを指します。予約ですのでご注意下さい。
  • 確認は確認操作を指し、このステップは実際に実行されるステップです。
  • キャンセルは元に戻す操作を指し、予約フェーズでのアクションを元に戻すことを意味します。

• 概念的には 2PC に似ていますが、TCC はコードによる 2 フェーズ コミットの人工的な実装です。

• TCC モデルにはトランザクション マネージャーの役​​割もあり、マルチポイントになり、クラスターが導入されます。 TCCグローバルトランザクションステータスを記録し、トランザクションをコミットまたはロールバックするために使用されます。

• タイムアウトを導入し、タイムアウト後に補正し、リソース全体をロックしない

• 利点

  • TCCはデータベースや異なるビジネスシステム間でトランザクションを実装できます

• デメリット

  • TCCはビジネスに大きな影響を及ぼし、ビジネスと密接に結びついています。

失効および確認操作の実行を再試行する必要がある場合があるため、操作のべき等性も保証する必要があります。

6. ローカルメッセージテーブル

• 各システムでローカルトランザクションを使用して分散トランザクションを実装する

• ローカル メッセージを格納するためのテーブルがあり、通常はデータベース内に配置されます。業務を実行する際、業務の実行とメッセージをメッセージ テーブルに格納する操作を同じトランザクションに配置して、メッセージがローカル テーブルに格納された後に業務が正常に実行されるようにします。

• バックグラウンド タスクは、定期的にローカル メッセージ テーブルを読み取り、正常に更新されていないメッセージをフィルター処理して、対応するサービスを呼び出します。サービス更新が成功すると、メッセージのステータスが変更されます。

• 再試行するには、対応するサービス メソッドがべき等であることを確認する必要があり、通常、再試行回数には最大数があります。最大数を超えた場合は、手動で処理するためにアラームを記録することができます。

• 最終的な一貫性が達成される

7. メッセージトランザクション

• MQトランザクションの使用

• まず、トランザクション メッセージまたは半分のメッセージをブローカーに送信します。メッセージが半分だからといって、メッセージが半分だという意味ではありませんが、このメッセージは消費者には見えません。メッセージが正常に送信された後、送信者はローカル トランザクションを実行します。

• 次に、ローカルトランザクションの結果に基づいて、ブローカーにコミットまたはロールバックコマンドを送信します。

• RocketMQ の送信者は、逆クエリ トランザクション ステータス インターフェイスを提供します。セミメッセージが一定期間内に操作要求を受信しない場合、ブローカーはリバース クエリ インターフェイスを使用して送信者のトランザクションが正常に実行されたかどうかを確認し、Commit コマンドまたは RollBack コマンドを実行します。

• コミットの場合、サブスクライバーはメッセージを受信して​​から、対応する操作を実行します。完了後、サブスクライバーはメッセージを消費できます。

• RollBack の場合、サブスクライバーはこのメッセージを受信しません。つまり、トランザクションは実行されていないことを意味します。

• メッセージトランザクションは結果整合性も実現します

8. ベストエフォート通知

• ローカル メッセージ テーブルもベスト エフォートと見なすことができ、トランザクション メッセージもベスト エフォートと見なすことができます。
• ベスト エフォート通知は、実際には柔軟なトランザクションのアイデアを表現しているだけです。つまり、トランザクションの最終的な一貫性を実現するために最善を尽くしました。
• SMS 通知など、時間に敏感でないサービスに適用されます。

9. 佐賀

• 長いトランザクションのソリューションは、長くて複数のビジネス プロセスがあるシナリオに適しています。

• 特に、レガシー システム サービスであるトランザクションに参加するサービスの場合、TCC モードでは 3 つのインターフェイスを提供できないため、Saga モードを使用できます。

• 各分散トランザクションの各実行操作またはステップは Ti です。たとえば、在庫の減算は T1、注文の作成は T2、支払いサービスは T3 です。次に、各Tiに対して、在庫C1の回復、注文のロールバックC2、支払いのロールバックC3などの対応する補償アクションCiがあります。

• 利点

  • ローカルトランザクションの1フェーズコミット、ロックフリー、高パフォーマンス
  • 参加者は非同期で高スループットで実行できる
  • 更新操作の逆操作は比較的理解しやすいため、補正サービスは簡単に実装できます。

• デメリット

  • 分離は保証されません（他のトランザクションを見ることができます）
    • Saga の操作モードは、電子メールの送信に似ています。送信された電子メールは正しく、受信者はそれを通常どおりに解釈します。メールが間違った相手に送信された場合は、受信者に前のメールを無視するように伝える別のメールを送信します。しかし、この操作は元に戻せない場合があります。
    • 例
      • 分散トランザクションでは、最初にユーザー A が再チャージされ、次にユーザー B の残高が差し引かれます。ユーザー A が正常に再チャージされたが、トランザクションがコミットされる前に残高が消費された場合、トランザクションがロールバックされたときに補償する方法はありません。
    • どう対処するか
      • ビジネスプロセスを設計する際には、「短期の支払いよりも長期の支払いの方が良い」という原則に従います。支払いが長期化するということは、顧客の資金が減り、金融機関の資金が増えることを意味します。機関の信頼性に基づいて、顧客に払い戻しを行うことができます。それどころか、不足分の支払いとなり、不足分は回収できない可能性があります。したがって、ビジネス プロセスの設計では、最初に支払いを差し引く必要があります。
      • いくつかのビジネス シナリオでは、最終的にビジネスを成功させることができます。ロールバックが失敗した場合は、最終的な一貫性の目的を達成するために、後続のプロセスを完了するために再試行を続けることができます。

• 2つの回復戦略

  • フォワードリカバリ: 実行に失敗したトランザクションについては、トランザクションの再試行が試行されます。ここでは、各サブトランザクションが最終的に成功するという前提があります。このアプローチは、成功が不可欠なシナリオに適しています。

  • 後方回復: トランザクションが失敗すると、完了したすべてのトランザクションが補償されます。これは、「最後に戻る」アプローチです。

• 2つのモード

  • オーケストレーション

    • これは、参加者がメッセージ メカニズムを通じて通信し、リスナーを通じて他の参加者から送信されたメッセージをリッスンして、後続の論理処理を実行する分散型モデルです。
    • アドバンテージ
      • シンプル: 各サブトランザクションは、操作を実行するときにイベント メッセージを発行するだけでよく、他のサブトランザクションはリッスンして処理します。
      • 疎結合: 参加者 (サービス) はイベントをサブスクライブすることで通信し、組み合わせの柔軟性を高めます。
    • 欠点
      • 理解が難しい
      • サービスの循環的な依存関係がある

  • コントロール

    • 参加者 (サービス) にどの操作 (サブトランザクション) を実行する必要があるかを指示する制御クラスを定義します。 Saga コントローラー クラスは、コマンドと非同期応答を通じて参加者と対話します。
    • アドバンテージ
      • 循環依存を避ける
      • 複雑さを軽減: すべてのトランザクションはコントローラーによって処理されます
      • テストが簡単
      • 拡張が簡単
    • 欠点
      • 依存型コントローラ: コントローラにロジックを集中させすぎることのリスク
      • 管理の難しさの増大：追加の管理および制御サービスが必要

10. 結論

• 2PC と 3PC は強力な一貫性トランザクションですが、データの不整合やブロッキングなどのリスクが残っており、データベース レベルでのみ使用できます。
• TCC は、より広範囲に適用できる補償取引の概念です。これはビジネス レベルで実装されるため、ビジネスへの影響がより大きくなります。各操作には、対応する 3 つのメソッドの実装が必要です。
• Saga は長いトランザクションのためのソリューションです。 TCC よりもシンプルですが、分離を保証することはできません。
• ローカル メッセージ、トランザクション メッセージ、ベスト エフォート通知はすべて最終的に一貫性のあるトランザクションであるため、時間に敏感でない一部のビジネスに適しています。