分散トランザクションと分散ロックは、分散システムにおける難しい点です。分散トランザクションについては、1 つの記事で完全に説明できない場合があります。私の習慣は、基本的な概念から始めて、段階的に紹介することです。まず、トランザクションにおける基本的な概念を整理します。基本的な概念をよく理解している場合は、「一貫性に関する議論」とそれに続く部分を直接読むことができます。私にとっては、要約して確認したり、彼とコミュニケーションしたり共有したりするのに便利です。

分散トランザクションとは何か

日常生活では、多くのことを完全に行うか、まったく行わないかのどちらかにする必要があります。一部だけを実行することはできません。そうしないと、他の複雑な問題が発生します。多くの人は送金の例を挙げるのが好きです。同じ口座で、Aさんは湖北省で500を送金し、Bさんは広東省で500を引き出しました。 A が送金した後、A の口座の金額は減額され、B の口座の金額は増額される必要があります。取引 = (A の口座から 500 が減額され、B の口座から 500 が増額されます)

このように複数のステップをまとめたものがトランザクションであり、すべてが実行されるか、まったく実行されないかのどちらかになります。データが複数のデータベースに保存されている場合、つまりデータベース間の呼び出しがある場合、ネットワークの安全性と遅延のために、トランザクションの分散実行をどのように保証できるでしょうか?実行の途中で停電が起きたらどうなるでしょうか?分散トランザクションについて説明する前に、一般的にACIDとして知られるトランザクションのいくつかの特性について簡単に確認し、以下で 1 つずつ説明しましょう。

アトミック

化学において、分子は H2O、CO2H2O、CO2 などの化学的性質を維持する最小単位です。原子で構成された物質の場合、原子は FeFe などの物質的性質を維持し、つまり分割不可能です。陽子と中性子に分割すると、それらはもはや私たちが物質と考えるものではなくなります。ここでのアトミック性についても同じことが言えます。つまり、トランザクションをこれ以上分割することはできません。たとえば、上記のトランザクションは 2 つのプロセスで構成されているように見えますが、分割すると、想定どおりのプロセスにはなりません。したがって、トランザクションはそれ以上分割できず、アトミック性を持ちます。

一貫性

一貫性も分かりやすいです。上記の 2 つの口座について、銀行がここにいくら入金されているかを知りたい場合、取引が実行される前は、口座 A には 500 元、口座 B にはお金がなく、銀行口座の合計は 500 元になります。取引が実行されると、アカウント A にはお金がなく、アカウント B には 500 元が入っています。つまり、この500元は確実であり、口座Aに500元があり、口座Bにも500元があるということはあり得ません。そうすると、データに矛盾が生じます。この場合、トランザクション内のいくつかのステップの実行に問題があり、一貫性のない中間データが生成されることを意味します。

分散システムでは、結果として、同時に複数のクエリを実行すると、同じ結果が生成されるはずです。

分離

トランザクションが完了していない場合、別のトランザクションはそれに影響を与えません。つまり、B が C に 1000 を送金した場合、それはトランザクション 2 として記録されます。

取引 1 = (アカウント A が 500 を減額、アカウント B が 500 を増額)

取引 2 = (アカウント B が 1000 を減額、アカウント C が 1000 を増額)

これら 2 つの取引の間には影響はなく、つまり、A が送金した 500 元は C の口座には届きません。

耐久性

永続性とは、一般的に、データがディスクに書き込まれ、簡単に変更されないことを意味します。ここで、トランザクションがコミットされると、データベースに影響が及び、失われることはありません。これは、システムが大規模化するにつれて、可用性、保守性、スループットなどの技術指標を向上させるために、元のアーキテクチャを改善し、ビジネス計算の問題を解決したとしても、データベースがシステム全体のボトルネックになることを意味します。

一貫性に関する議論

ACID は本質的にデータの一貫性を保護することです。ただし、データの永続化によりデータベース操作がトリガーされ、効率が低下します。そのため、一貫性（効率性）については、強い一貫性、弱い一貫性、結果的一貫性といった議論が行われてきました。

強い一貫性

任意の読み取りでは、特定のデータの最後に書き込まれたデータを読み取ることができます。システム内のすべてのプロセスによって認識される操作の順序は、グローバル クロックでの順序と一致します。つまり、いつでもすべてのノードのデータは同じであるため、データが変更されるとすぐにデータベースに書き込まれる必要があります。

一貫性が弱い

データが更新された後、データベースに書き込む必要はなく、時間内にすべてのノードに同期する必要もありません。つまり、現時点では、データと実際のデータの間には若干の矛盾がある可能性があります。アーキテクチャでは、後続のアクセスがデータの一部またはすべてにしかアクセスできないことを許容できる場合、それは弱い一貫性です。

最終的な一貫性

任意のノード上の同じデータがいつでも同じであるという保証はありません。つまり、一部のノード データは正確で、一部は不正確である可能性がありますが、時間が経つにつれて、異なるノード上の同じデータは常に同様の方向に変化します。簡単に言えば、一定期間が経過すると、ノード間のデータは最終的に一貫した状態になります。

3 種類の一貫性のうち、強い一貫性のあるデータは信頼性が高いですが、すべてのデータベースで常にデータの一貫性を維持する必要があるため、効率は低くなります。データが統一されていない場合は、リクエストに応えることができません。同時実行性の高いシナリオでは、エクスペリエンスはあまり良くありません。したがって、実際の使用においては、ビジネス上の選択に応じて一貫性が異なります。買い物をするとき、アカウントの支払いは強い一貫性を持たなければなりませんが、商品の在庫データは必ずしも強い一貫性を持つ必要はありません。商品の下のコメントに関しては、弱い粘稠度を選択することもできます。

サブライブラリとサブテーブル

以前、クラスターの AKF 分割原則 (Redis クラスターの AKF 分割原則) について説明しましたが、これは大まかに言うと、ハードウェアのパフォーマンスには上限があることを意味します。ハードウェアが要求トラフィックをサポートできない場合、トラフィックを別のサーバーに分散できます。 AKF 分割の Y 軸分割と Z 軸分割は、ビジネス分割とデータ分割であり、データベース内のデータを分割して別の場所に保存することも含まれます。これをサブライブラリおよびサブテーブルと呼びます。複数のマシンでの保存と読み込みのために、異なるタイプのデータが異なるデータベースに保存されます。このように、従来のトランザクションメカニズム ACID は正常に動作できません。

データベースとテーブルのシャーディングの内容は、データのセグメント化（シャーディング）と、セグメント化後のデータの配置と統合です。具体的には、データ分割とは、複数のデータベースにデータを分散して格納することで、単一データベースのデータ量が少なくなり、ホスト数の拡張により単一データベースの性能問題が緩和され、データベースの運用性能を向上させるという目的を達成します。

データセグメンテーションは、セグメンテーションの種類によって、垂直（縦方向）セグメンテーションと水平（横方向）セグメンテーションの 2 種類に分けられます。

垂直分割

垂直セグメンテーションには、垂直データベース セグメンテーションと垂直テーブル セグメンテーションという 2 つの一般的なタイプがあり、これらは意味が似ています。

垂直データベース パーティショニングとは、ビジネス結合に基づいて、相関性の低い異なるテーブルを異なるデータベースに格納することを意味します。このアプローチは、大規模なシステムを複数の小規模なシステムに分割し、業務分類に応じて個別に分割するのと似ています。 「マイクロサービス ガバナンス」アプローチと同様に、各マイクロサービスは個別のデータベースを使用します。図に示すように:

垂直サブテーブルも同様です。たとえば、名前、ID カード、性別、身長、体重、都道府県、市区町村、専攻、G スポットなど、人物に関するすべての情報がテーブルに含まれている場合、そのテーブルを 3 つのテーブルに分割できます。

最初の表には基本情報（名前、IDカード、性別、身長、体重）のみが含まれています。

2 番目の表には、原産地情報 (州、市、地区、村) が含まれています。

3 番目のテーブルには学習情報 (メジャー、G スポット) が含まれています。

垂直分割のメリットとデメリット

垂直セグメンテーションの利点:

• 業務システムレベルでの結合を解決し、業務を明確にする
• マイクロサービスのガバナンスと同様に、さまざまなビジネスのデータを階層的に管理、維持、監視、拡張することもできます。
• 同時実行性の高いシナリオでは、垂直セグメンテーションにより、IO、データベース接続数、および単一マシンのハードウェア リソースのボトルネックをある程度改善できます。

垂直スライスの欠点:

• 一部のテーブルは結合できず、インターフェース集約を通じてのみ解決できるため、開発の複雑さが増します。
• 分散トランザクション処理は複雑である
• 1つのテーブルにデータが多すぎるという問題がまだ残っています（水平方向のセグメンテーションが必要です）

水平分割

上記のようにデータベースを垂直に分割した後、データベースがまだ非常に大きい場合 (たとえば、保存されているデータが非常に大きい場合)、データベースを水平に分割できます。

上記の水平分割は ID 範囲に基づいています。たとえば、userId 値が 1 から 10000 までのレコードは最初のデータベースに割り当てられ、userId 値が 10001 から 20000 までのレコードは 2 番目のデータベースに割り当てられます。ある意味では、一部のシステムで使用されている「コールド データとホット データの分離」も同様の手法です。これは、あまり使用されていない履歴データを他のデータベースに移行し、ビジネス機能の観点からホット データのみにクエリを提供するというものです。

上記のユーザー ID 範囲による分割に加えて、ハッシュ操作による分割も実行できますが、ここでは詳細には説明しません。

水平分割のメリットとデメリット

水平分割の利点は次のとおりです。

• 単一のテーブルサイズを制御可能
• 当然横方向への拡張も容易です。後でシャード クラスター全体を拡張する場合は、他のシャードからデータを移行せずにノードを追加するだけで済みます。
• 範囲検索にシャード フィールドを使用すると、連続シャードは高速クエリのためにシャードをすばやく見つけることができるため、シャード間のクエリの問題を効果的に回避できます。

水平分割の欠点:

• ホットデータはパフォーマンスのボトルネックになります。継続的なシャーディングではデータ ホットスポットが発生する可能性があります。たとえば、時間フィールドでシャーディングする場合、一部のシャードには、頻繁に読み書きされる可能性のある最新の期間のデータが保存され、一部のシャードには、ほとんどクエリされない履歴データが格納されます。

シャーディングによって生じる問題

データベースとテーブルのシャーディングにより、単一のマシンと単一のデータベースによってもたらされるパフォーマンスのボトルネックとプレッシャーを効果的に軽減し、ネットワーク IO、ハードウェア リソース、接続数のボトルネックを打破できます。しかし、いくつかの問題も生じます。前述したように、トランザクションには一連のサブ操作が含まれており、それらはすべて実行されるか、まったく実行されないかのいずれかになります。ただし、データベース シャーディング後は、トランザクションに複数のデータベースまたは複数のテーブルが関係する可能性があり、ネットワークが不安定になるため、トランザクション実行の難易度が高くなります。従来のトランザクションと区別するために、データベースとテーブルのシャーディング後のトランザクションを分散トランザクション（クロスシャードトランザクション）と呼びます。

クロスシャードトランザクションも分散トランザクションです。簡単な解決策はありません。一般的には、「XA プロトコル」と「2 フェーズ コミット」を使用して処理できます。

分散トランザクションにより、データベース操作の原子性を最大限に保証できます。ただし、トランザクションを送信する際には複数のノードを調整する必要があり、トランザクションを送信するタイミングが延期され、トランザクションの実行時間が長くなります。これにより、共有リソースにアクセスするときにトランザクションが競合したりデッドロックが発生する可能性が高くなります。データベース ノードの数が増加するにつれて、この傾向はますます深刻になり、データベース レベルでのシステムの水平拡張の足かせになります。

最終的な一貫性

パフォーマンス要件は高いが一貫性要件は低いシステムの場合、システムのリアルタイム一貫性は要求されないことがよくあります。許容された期間内に最終的な一貫性が達成される限り、トランザクション補償を使用できます。実行中にエラーが発生した直後にトランザクションをロールバックする方法とは異なり、トランザクション補正は事後的な修復手段です。一般的な実装方法には、データの照合チェック、ログに基づく比較、標準データ ソースとの定期的な同期などがあります。トランザクション補正もビジネス システムと連動して考慮する必要があります。

分散トランザクションソリューション

これについて話す前に、CAP 原則と Base 理論を簡単に確認する必要があります。分散トランザクションは ACID の固定トランザクションとは異なるため、分散シナリオでは BASE 理論に基づいて柔軟なトランザクションの概念が提案されています。柔軟なトランザクションを通じて最終的な一貫性を実現するには、いくつかの特性に依存する必要がありますが、ソリューションによって要件が異なるため、特定のソリューションではこれらの特性がすべて満たされない可能性があります。しかし、いずれかが満たされていない場合、柔軟な取引を行うことは不可能です。

CAP原則

おそらくほとんどの人は CAP について少なくとも 100 回は聞いたことがあるでしょう。 CAP は「3 つのうち 2 つを選択する」関係であると多くの人が言っており、AC のような状況が存在すると誤解しています。しかし、CAP は実際には「2 つのうち 1 つを選択する」関係です。これは2012年の論文で説明されている: CAP 12年後: 「ルール」はどのように変化したか

これは、前の 3 つの選択肢のうち 2 つを選択するステートメントの修正に相当します。 CAP の P (パーティション許容度) は必須です。 P を満たしながら、A (可用性) と C (一貫性) を同時に満たすことは困難です。しかし、その後、収穫、収量、およびスケーラブルな耐性システムという別の記事がありました。この論文は、上記の「CAP 12年後」論文に基づいて執筆されました。主に収穫と収量の概念を提案し、上記の論文で議論された内容についてさらに詳しく説明しました。簡単に言えば、P が満たされた後、制約を緩和して C と A を考慮に入れることができます。それはどちらか一方という関係ではありません。これは行き過ぎだ。

Pはなぜ必要なのでしょうか?

CAP 原則ではなぜパーティション耐性が必要なのでしょうか?まず、パーティション許容度とは何かを理解する必要があります。パーティションはネットワークを指します。ネットワーク クラスターは多数のサーバーで設計されています。ある瞬間にネットワークが不安定な場合、それはネットワークを異なるゾーンに分割することと同じです。 2つのゾーンに分割されているとします。この時点で、取引がある場合:

パーティション1にメッセージを送信: AがBに100元を送金、パーティション2にメッセージを送信: AがBに200元を送金

2 つのパーティションの場合、次の 2 つの状況が考えられます。

a) 利用不可、つまり 2 つの取引のうち少なくとも 1 つは受け入れられません。

b) 一貫性がなく、半数の人は A が B に 100 元を送金するのを見ており、残りの半数は A が B に 200 元を送金するのを見ています。

したがって、パーティション許容度を満たす必要があります。解決策は、データ項目を複数のノードにコピーすることです。その後、パーティションが発生した後、このデータ項目はさまざまなゾーンに分散される可能性があります。許容度が増します。

基本理論

多くの場合、強力な一貫性のあるシステムは必要ないため、後にデータの一貫性と可用性について議論されたときには、主に強力な一貫性のある ACID または最終的に一貫性のある BASE に焦点が当てられました。 BASE は、CAP における一貫性と可用性のトレードオフの結果です。これは、大規模なインターネット分散システムの実践の要約から生まれ、CAP 定理に基づいて徐々に進化してきました。基本的な考え方は、強力な一貫性を実現できない場合でも、各アプリケーションが独自のビジネス特性に基づいて適切な方法を使用し、システムが最終的な一貫性を実現できるようにするというものです。

BASE 理論は、「Basically Available (基本的に利用可能)」、「Soft State (ソフト ステート)」、「Eventually Consistent (最終的に一貫性がある)」という 3 つのフレーズの略語です。

基本的な使いやすさ

システムに予期せぬ障害が発生しているが、まだ使用可能であると想定します。通常のシステムと比較すると：

1. 応答時間の損失: 通常の状況では、検索エンジンは 0.5 秒以内にユーザーに結果を返しますが、基本的に利用可能な検索エンジンは 2 秒以内に結果を返すことができます。
2. 機能の損失: 電子商取引の Web サイトでは、通常の状況では、ユーザーは各注文を正常に完了できます。ただし、大規模なセール期間中は、ショッピング システムの安定性を保護するために、一部の消費者はダウングレード ページに誘導されることがあります。

これを基本可用性と呼びます

ソフトステート

アトミック性と比較すると、複数のノードのデータのコピーが一貫していることが必要となり、これは「ハード状態」となります。ソフト状態とは、システム内のデータが中間状態で存在することを許可し、その状態がシステム全体の可用性に影響を与えないと想定することを意味します。つまり、システムが複数の異なるノード上のデータ コピーでデータ遅延を持つことを許可することを意味します。

最終的な一貫性

上記で述べたソフト状態ですが、常にソフト状態であるわけではなく、時間制限があるはずです。期限後は、すべてのレプリカがデータの一貫性を維持することが保証され、最終的なデータの一貫性が達成されます。この時間制限は、ネットワークの遅延、システムの負荷、データ複製ソリューションの設計などの要因によって異なります。

Baseの中心的なアイデアは次のとおりです。

強い一貫性は実現できないため、各アプリケーションは、独自のビジネス特性に基づいて、システムが最終的な一貫性を実現できるように適切な方法を採用できます。ベース理論を使用すると、分散トランザクションの処理のアイデアについて話し始めることができます。

2相コミットプロトコル

2 フェーズ コミット (2PC) は、その名前が示すように、分散トランザクション プロセスを投票とトランザクションの送信の 2 つの段階に分割します。データベース クラスター全体を正常に実行できるようにするために、プロトコルは、データベース クラスター全体のすべてのノードの操作を調整する単一のコーディネーターポイントを指定します。説明を簡略化するために、データベース クラスター内の各ノードを参加者と呼びます。 3 フェーズ コミット プロトコルには、コーディネーターと参加者の 2 つのロール定義も含まれていますが、これについては後で説明します。

フェーズ1: 投票

この段階の主な目的は、データベース クラスター内の各参加者がトランザクションを正常に実行できるかどうかを確認することです。具体的な手順は次のとおりです。

1. コーディネーターはすべての参加者にトランザクション実行要求を送信し、参加者がトランザクション実行結果をフィードバックするのを待ちます。
2. トランザクション参加者は要求を受信した後、トランザクションを実行しますが、コミットせず、トランザクション ログを記録します。
3. 参加者は、トランザクション実行のステータスに関するフィードバックをコーディネータに提供し、コーディネータからの後続の指示を待機します。

フェーズ2: トランザクションコミット

コーディネーターの問い合わせの最初のフェーズの後、各参加者は自分のトランザクションの実行ステータスを返信します。現時点では3つの可能性があります:

1. 参加者全員が、取引を正常に実行できたと回答しました。
2. 1 人以上の参加者が、トランザクションの実行が失敗したと応答しました。
3. コーディネーターの待機がタイムアウトしました。

最初のケースでは、コーディネーターはすべての参加者にトランザクションを送信するように通知を送信します。具体的な手順は次のとおりです。

1. コーディネーターは各参加者にコミット通知を送信し、トランザクションをコミットするように要求します。
2. トランザクションコミット通知を受信した後、参加者はコミット操作を実行し、占有されているリソースを解放します。
3. 参加者はトランザクションのコミット結果情報をコーディネータに返します。

2 番目と 3 番目のケースでは、コーディネーターは参加者がトランザクションを正常に実行できないと判断します。クラスター全体のデータの一貫性を保つために、各参加者にトランザクションのロールバック通知が送信されます。具体的な手順は次のとおりです。

1. コーディネータは各参加者にトランザクション ロールバック通知を送信し、トランザクションをロールバックするよう要求します。
2. トランザクションのロールバック通知を受信した後、参加者はロールバック操作を実行し、占有されているリソースを解放します。
3. 参加者は、トランザクションのロールバック結果情報をコーディネータに返します。

2 フェーズ コミット プロトコルは、分散データベース データの強力な一貫性の問題を解決します。実際のアプリケーションでは、トランザクション操作の原子性を解決するために使用されることが多いです。次の図は、コーディネーターと参加者間の状態遷移を示しています。

コーディネータの観点から見ると、投票を開始した後、WAIT 状態に入り、すべての参加者がそれぞれのトランザクション実行ステータスに応答するのを待機し、すべての参加者からの応答を受信した後、次のステップとしてコミット メッセージを送信するか、ロールバック メッセージを送信するかを決定します。

参加者の観点から見ると、コーディネーターの投票要求に応答した後、READY 状態 (トランザクションを正常に実行できる状態) に入り、コーディネーターの最終決定通知を待ちます。通知を受信すると、決定に基づいてコミットまたはロールバック操作を実行できます。

2 フェーズ コミット プロトコルは原理的には単純で実装も簡単ですが、次のような欠点も明らかです。

• 単一点問題

コーディネーターは、2 フェーズ コミット プロセス全体において重要な役割を果たします。コーディネーターが配置されているサーバーがダウンすると、データベース クラスター全体の正常な動作に影響が出ます。たとえば、第 2 フェーズでは、コーディネータが障害のためにトランザクションのコミットまたはロールバック通知を正常に送信できない場合、参加者はブロックされた状態のままになり、データベース クラスター全体がサービスを提供できなくなります。

• 同期ブロッキング

2 フェーズ コミット実行プロセス中、すべての参加者はコーディネータの統一されたスケジュールに従う必要があります。この期間中はブロックされた状態となり、他の操作を実行できないため、非常に非効率的です。

• データの不整合

2 フェーズ コミット プロトコルは分散データの強力な一貫性を実現するように設計されていますが、データの不整合が発生する可能性は依然として存在します。たとえば、第 2 フェーズでは、コーディネーターがトランザクション コミット通知を送信したが、ネットワークの問題により、通知は一部の参加者によってのみ受信され、コミット操作が実行されるものとします。残りの参加者は通知を受信して​​いないためブロックされ、データの不整合が発生します。

上記の問題は、タイムアウト機構と相互問い合わせ機構を導入することで、かなり解決できます。

タイムアウトメカニズム

コーディネータは、指定された時間内にすべての参加者から応答を受信しなかった場合、自動的に WAIT 状態を終了し、すべての参加者にロールバック通知を送信できます。参加者の場合、READY 状態であっても、指定された時間内にコーディネータから第 2 フェーズの通知を受信しなかった場合、コーディネータがコミット通知を送信する可能性があり、この時点でロールバックを実行するとデータの不整合が発生するため、任意にロールバック操作を実行することはできません。

相互協議メカニズム

この時点で、相互問い合わせメカニズムに介入して、参加者 A が他の参加者 B に実行ステータスについて問い合わせられるようにすることができます。 B がロールバックまたはコミット操作を実行する場合、A は B と同じ操作を大胆に実行できます。この時点で B が READY 状態に達していない場合は、コーディネータがロールバック通知を送信したと推測できます。 B も READY 状態の場合、A は他の参加者に質問を続けることができます。すべての参加者が READY 状態にある場合にのみ、2 フェーズ コミット プロトコルを処理できず、長期のブロック状態に陥ります。

3相コミットプロトコル

3 フェーズ コミット (3PC): 2 フェーズ コミットの問題に対処するために、3 フェーズ コミット プロトコルでは、事前クエリフェーズとタイムアウト戦略を導入し、クラスター全体のブロック時間を短縮してシステム パフォーマンスを向上させます。 3 フェーズ コミットの 3 つのフェーズは、事前クエリ (can_commit)、事前コミット (pre_commit)、およびトランザクション コミット (do_commit) です。

フェーズ1: 事前調査

このフェーズでは、コーディネーターは各参加者にトランザクションを正常に実行できるかどうかを尋ねます。参加者は自身の状況に基づいて推定値を返信します。トランザクションの実際の実行と比較すると、このプロセスは軽量です。具体的な手順は次のとおりです。

1. コーディネータは、各参加者にトランザクション照会通知を送信し、トランザクション操作を実行できるかどうかを尋ね、応答を待ちます。
2. 各参加者は、自身の状況に基づいて推定値を返信します。トランザクションを正常に実行できると判断された場合は確認メッセージを返して準備状態に入り、そうでない場合は否定メッセージを返します。

フェーズ2: 事前提出

このフェーズでは、コーディネーターは第 1 フェーズの調査結果に基づいて対応するアクションを実行します。主な調査結果は 3 つあります。

1. 参加者全員が確認の返信をしました。
2. 1 人以上の参加者が否定的な回答を返しました。
3. コーディネーターの待機がタイムアウトしました。

最初のケースでは、コーディネーターがすべての参加者にトランザクション実行リクエストを送信します。具体的な手順は次のとおりです。

1. コーディネーターは、すべてのトランザクション参加者にトランザクション実行通知を送信します。
2. 通知を受け取った後、参加者はトランザクションを実行しますが、コミットはしません。
3. 参加者はトランザクションの実行ステータスをクライアントに返します。

上記の手順では、参加者がタイムアウトを待つと、トランザクションは中止されます。 2 番目と 3 番目のケースでは、コーディネータはトランザクションを正常に実行できないと判断し、各参加者に中止通知を送信して、準備状態を終了するように要求します。具体的な手順は次のとおりです。

1. コーディネーターはすべてのトランザクション参加者に中止通知を送信します。
2. 参加者は通知を受け取った後、トランザクションを中止します。

フェーズ3: トランザクションコミット

第 2 フェーズのトランザクションが中断されない場合、このフェーズのコーディネーターは、トランザクション実行によって返された結果に基づいて、トランザクションをコミットするかロールバックするかを決定します。状況は3つあります。

1. すべての参加者は正常にトランザクションを実行できます。
2. 1 人以上の参加者がトランザクションの実行に失敗しました。
3. コーディネーターの待機がタイムアウトしました。

最初のケースでは、コーディネーターが各参加者に対してトランザクション送信要求を開始します。具体的な手順は次のとおりです。

1. コーディネーターはすべての参加者にトランザクションコミット通知を送信します。
2. 通知を受信した後、すべての参加者はコミット操作を実行し、占有されているリソースを解放します。
3. 参加者はトランザクションの送信結果をコーディネーターにフィードバックします。

2 番目と 3 番目のケースでは、コーディネーターはトランザクションを正常に実行できないと判断し、各参加者にトランザクション ロールバック要求を送信します。具体的な手順は次のとおりです。

1. コーディネーターはすべての参加者にトランザクション ロールバック通知を送信します。
2. 通知を受信した後、すべての参加者はロールバック操作を実行し、占有されているリソースを解放します。
3. 参加者はトランザクションのロールバック結果をコーディネータにフィードバックします。

この段階では、コーディネータまたはネットワークの問題により参加者がコーディネータからのコミットまたはロールバック要求を受信できなかった場合、参加者は 2 フェーズ コミットの場合のようにブロックされず、タイムアウトを待機した後にコミットを続行します。これにより、2 フェーズ コミットに比べて同期ブロックが軽減されますが、データの不整合を完全に回避することはできません。 2 フェーズ コミット プロトコルで長時間のブロック状態が発生する確率は依然として非常に低いです。したがって、3 フェーズ コミット プロトコルは 2 フェーズ コミット プロトコルよりもデータの一貫性に関して信頼性が高いですが、実際のシステムでは効率の問題により 2 フェーズ コミット プロトコルの方が一般的です。

TCC モード

TCC は、Try (試す)、Confirm (確認する)、Cancel (キャンセルする) の頭字語です。それぞれの責任は次のとおりです。

試してください: リソースの予約を担当します (たとえば、ステータスが PENDING の新しい注文を作成します)。

ビジネス検査を行うには、簡単に言えば、すでに使用されているリソースを予約することはできません。

予約済みのリソースを分離します。

確認: 着陸のために予約されたリソースの責任者

実際のビジネス実行では、try フェーズで予約されたリソースが使用され、べき等性があります。

キャンセル: 予約されたリソースをキャンセルする責任があります

ユーザーは、独自のビジネス シナリオに応じて、Try、Confirm、Cancel の 3 つの操作を実装する必要があります。トランザクション イニシエーターは、最初のフェーズで Try メソッドを実行し、送信の 2 番目のフェーズで Confirm メソッドを実行し、ロールバックの 2 番目のフェーズで Cancel メソッドを実行します。

予約済みリソースについて少し説明します。リソースは限られているため、予約されたリソースには時間制限があります。予約されたリソースが長時間確認されない場合（この状況をタイムアウトと呼びます）、参加者は自分でそれをキャンセルします。言い換えれば、参加者はリソースを自己管理する能力を持ち、イニシエーターの問題によるリソースの長期占有を回避できます。

TCC は、業務検査および取引キャンセルの機能を追加します。同時に、TCC は 2PC データベース レベルのアクションをサービス レベルに引き上げます。違いは、TCC のすべてのアクションはローカル トランザクションであり、各ローカル トランザクションはアクションが完了した後にデータベースにコミットされることです。

• Tryは、ビジネスチェックロジックを追加した2PCのコミット要求フェーズに相当します。
• 確認は2PCのコミットフェーズのコミットアクションと同等である。
• キャンセルは2PCのコミットフェーズのロールバックアクションと同等である。

プロセス手順:

1. イニシエーターはすべての参加者にTryを送信します
2. 各参加者はTryを実行し、リソースを予約する
3. イニシエーターは参加者全員からトライ結果を受け取る
4. イニシエーターは参加しているすべての部屋に確認/キャンセルを送信します
5. 各参加者は確認/キャンセルを実行する
6. 開始者は参加者全員から確認/キャンセル結果を受け取ります

このプロセスは 2 フェーズ コミットと非常によく似ています。