では--CAP BASE理論や分散システムの理論分散システムの特性と理論について、私たちは主の簡単な紹介は、具体的に我々はそれを満たしていますか？ここでは、達成するためにアルゴリズムを使用する必要があります。2PCと3PCは、主に分散トランザクションに基づく分散整合性アルゴリズムです。

分散システムでは、各ノードは互いに物理的に独立しており、ネットワークを介して通信および調整します。トランザクションメカニズムが存在するため、各独立ノードでのデータ操作がACIDを満たすことが保証されます。ただし、互いに独立したノードは、他のノードのトランザクションの実行ステータスを正確に知ることができません。

したがって、理論的には、2つのマシンは理論的に一貫した状態に到達できませんでした。分散展開の複数のマシンでデータの一貫性を維持する場合は、すべてのノードですべてのデータ書き込み操作が実行されるか、まったく実行されないようにする必要があります。

ただし、マシンがローカルトランザクションを実行する場合、他のマシンでのローカルトランザクションの実行結果を知ることはできません。そのため、このトランザクションをコミットするのか、ロールバックするのかはわかりませんでした。したがって、従来の解決策は、「コーディネーター」コンポーネントを導入して、すべての分散ノードの実行を均一にスケジュールすることです。2PCと3PCを使用すると、分散された強力な一貫性と分散トランザクションを実現できます。

分散トランザクション

一般に、複数のテーブルの操作など、データベースの内部トランザクション処理は、ローカルトランザクションとして扱われます。データベースのトランザクション処理オブジェクトはローカルトランザクションですが、分散トランザクション処理のオブジェクトはグローバルトランザクションです。いわゆるグローバルトランザクションは、分散トランザクション処理環境を指します。作業を完了するには、複数のデータベースが連携して動作する必要がある場合があります。この作業はグローバルトランザクションです。

たとえば、いくつかの異なるデータベースがグローバルトランザクションで更新される場合があります。データベースの操作はシステムのあらゆる場所で行われますが、サブミットまたはロールバックする必要があります。現時点では、データベースの内部操作への送信は、自身の操作の成功だけでなく、グローバルトランザクションに関連する他のデータベースの操作の成功にも依存しています。いずれかのデータベースの操作が失敗した場合、このトランザクションのすべての参加者データベースによって実行されるすべての操作はロールバックする必要があります。

2PC

2PC（2フェーズコミット）、つまり2フェーズコミット、アルゴリズムの考え方はおおよそ次のとおりです。参加者は、操作の成功または失敗をコーディネーターに通知し、コーディネーターは、すべての参加者のフィードバック情報に基づいて、各参加者が操作を送信するか、操作を中止するかを決定します。

2PCは、分散トランザクションのアトミックな問題を解決するために使用されます。いわゆる2つの段階とは、第1段階：準備段階（投票段階）および第2段階：提出段階（実行段階）を指します。

第1段階：準備段階

トランザクションコーディネーター（トランザクションマネージャー）は、準備メッセージを各参加者（リソースマネージャー）に送信します。各参加者は、失敗（権限検証失敗など）を直接返すか、トランザクションをローカルで実行してローカルのやり直しログと元に戻すログを書き込みます。、しかし提出せず、成功または失敗をコーディネーターに報告してください。
ここに画像の説明を挿入
具体的な手順：

コーディネーターノードは、送信操作（投票）を実行できるかどうかをすべての参加者ノードに尋ね、各参加者ノードの応答の待機を開始します。
参加ノードは、クエリが開始されるまですべてのトランザクション操作を実行し、元に戻す情報とやり直し情報をログに書き込みます。（注：成功した場合、実際には、各参加者はすでにトランザクション操作を実行していますが、コミットしていません）
各参加者ノードは、コーディネーターノードによって開始されたクエリに応答します。参加者ノードのトランザクション操作が実際に正常に実行された場合は、「同意する」メッセージを返し、参加者ノードのトランザクション操作が実際に失敗した場合は、「中止」メッセージを返します。

第2段階：提出段階

コーディネーターは、参加者の失敗メッセージを受信するかタイムアウトになると、ロールバックメッセージを各参加者に直接送信します。それ以外の場合は、コミットメッセージを送信します。コーディネーターは、コーディネーターの指示に従ってコミットまたはロールバック操作を実行します。すべてのトランザクション処理で使用されているロックリソースを解放します。（注：ロックリソースは最終段階で解放する必要があります。）

注：2PCでは、コーディネーターがタイムアウトを待機すると、ロールバック操作が実行されます。

ここに画像の説明を挿入

手順は次のとおりです（成功した場合、トランザクションをコミットします）。

コーディネーターノードは、すべての参加ノードに「コミット」要求を発行します。
参加者ノードは、操作を正式に完了し、トランザクション期間全体で占有されていたリソースを解放します。
参加者ノードは、「完了」メッセージをコーディネーターノードに送信します。
コーディネーターノードは、すべての参加者ノードから「完了」メッセージを受信した後でトランザクションを完了します。

失敗した場合は、トランザクションを中止します。

コーディネーターノードは、すべての参加者ノードに「ロールバック」リクエストを発行します。
参加ノードは、以前に書き込まれた取り消し情報を使用してロールバックを実行し、トランザクション期間全体で占有されていたリソースを解放します。
参加者ノードは、「ロールバック完了」メッセージをコーディネーターノードに送信します。
コーディネーターノードは、すべての参加者ノードから「ロールバック完了」メッセージを受信した後、トランザクションをキャンセルします。

2PCでは、最終結果に関係なく、第2フェーズで現在のトランザクションが終了し、2PC（2フェーズコミット）で実際にアトミック操作を提供できることがわかりました。その利点は非常に明確です。2PCの原理はシンプルで、実装に便利です。ただし、次のような多くの欠点もあります。

同期ブロッキング

2フェーズコミットプロセス中、参加しているすべてのノードはトランザクションをブロックし、他のノードからの応答を待っているため、他の操作を実行できません。この同期ブロッキングにより、分散システムのパフォーマンスが大幅に制限されます。

参加者がパブリックリソースを占有している場合、他のサードパーティノードはパブリックリソースにアクセスするためにブロックされた状態である必要があります。コーディネーターがサブミットまたは割り込みリクエストを送信するのを待つ間、各参加者は常にブロックし、コーディネーターが発行する時間はすべてに依存します参加者の応答時間、コーディネーターがダウンしている場合（単一障害点）、彼はここでブロックされており、合意に到達できません（3PCがタイムアウトサブミッション解決を導入）。

単一障害点

コーディネーターは2フェーズの提出プロセス全体で非常に重要です。提出フェーズ中にコーディネーターに問題が発生すると、プロセス全体が機能しなくなります。さらに重要なことに、他の参加者は常にトランザクションリソースをロックした状態になり、トランザクション操作を完了できなくなります。（コーディネーターがハングした場合、コーディネーターを再選することはできますが、コーディネーターのダウンタイムのために参加者がブロックされるという問題は解決できません）

一貫性のないデータ

コーディネーターがコミット要求をすべての参加者に送信すると、ローカルネットワークの異常が発生するか、すべてのコミット要求を送信する前にコーディネーターがクラッシュし、一部の参加者のみが最終的にコミット要求を受信するとします。ただし、コミット要求を受け取っていない他のマシンは、トランザクションのコミットを実行できません。その結果、分散システム全体でデータの不整合が発生します。

不完全なフォールトトレランスメカニズム

2フェーズコミットプロトコルは、比較的完全なフォールトトレランスメカニズムを設計していません。ノードに障害が発生すると、トランザクション全体の障害につながります。

3PC

3PC（3フェーズコミット）、または3フェーズコミットは、2フェーズコミット（2PC）の改良版です。「最初の段階：準備段階」の2つの段階を2つの合意に分割し、CanCommit、PreCommit、DoCommitの3つの段階を形成しました。

2フェーズコミットとは異なり、3フェーズコミットには2つの変更点があります。

タイムアウトメカニズムを導入します。（参加者のタイムアウト送信戦略、DoCommitフェーズの参加者は、コーディネーターのタイムアウトを待機すると、参加者の同期ブロッキングの問題を解決するためにトランザクションを送信し、単一障害点が発生しても合意に到達し続けることができます）
CanCommitは2PCに基づいて追加されます。これにより、同期ブロッキングのスコープと可能性が効果的に削減され、DoCommitがタイムアウトした後にトランザクションをコミットすることも可能になります。

ここに画像の説明を挿入

CanCommitフェーズ

3PCのCanCommitフェーズでは、コーディネーターはコミット要求を参加者に送信します。参加者が送信できると考える場合、参加者はYes応答を返し、そうでない場合はNo応答を返します。

トランザクションの問い合わせコーディネーターは参加者にCanCommitリクエストを送信します。トランザクションのコミット操作を実行できるかどうかを確認します。次に、参加者の応答を待ち始めます。
応答のフィードバック参加者がCanCommit要求を受け取った後、通常の状況では、トランザクションが正常に実行できると信じている場合は、Yesの応答を返し、準備状態に入ります。そうでなければフィードバックいいえ

注意：上の図を見てください。2PCとは異なり、ここではトランザクション操作を実行しません。実際にはトランザクション操作を実行します。元に戻すとやり直しのトランザクションログは、2番目のPreCommitステージに記録されます。

この段階のため、2PC送信のブロック時間が大幅に短縮されます。2PC送信では、3つのデータベースがある場合、3番目のデータベースに問題がありますが、2PCコーディネーターは準備メッセージを直接送信して、すべてのデータベースがトランザクション操作を実行し、最初の2つのデータベースはトランザクション操作を正常に実行しますが、3番目のデータベースに問題があるか、接続に到達できません。このとき、コーディネーターがトランザクション操作の中断を開始し、最初の2つのデータベースはロールバックする必要があります出て行け。3PCのCanCommitフェーズでは、3番目のデータベースの異常がすぐに見つかり、それが直接中断されます。

コミット前フェーズ

CanCommitフェーズ中に上記の状況が発生した場合、つまり、コーディネーターがすべての参加者からYes応答を受け取らないか、フィードバックがない場合、またはタイムアウトを待った後、トランザクションは中断されます。

割り込み要求の送信コーディネーターはすべての参加者に中止要求を送信します。
トランザクションの中断パーティシパントがコーディネーターから中止要求を受け取った後（またはタイムアウト後、コーディネーターが要求を受け取っていない場合）、トランザクションは中断されます。

コーディネーターがすべての参加者から受け取ったフィードバックが「はい」の応答である場合、トランザクションの事前実行は次のように実行されます。

事前コミット要求の送信コーディネーターは、PreCommit要求を参加者に送信し、準備段階に入ります。
トランザクションの事前コミットメント参加者がPreCommitリクエストを受信した後、トランザクション操作を実行し、取り消しとやり直しの情報をトランザクションログに記録します。
応答のフィードバック参加者がトランザクション操作を正常に実行すると、ACK応答が返され、最後の指示を待ち始めます。

DoCommitフェーズ

この段階での実際のトランザクション送信は、次の2つの状況に分けることもできます。最初のケースは、参加者から送信されたACKの正常な応答を調整して受信することです。その後、参加者はコミット前の状態からコミット状態に移行します。そして、すべての参加者にDoCommitリクエストを送信します。

トランザクションの送信参加者はdoCommitリクエストを受信した後、正式なコミットトランザクションの送信を実行します。トランザクションのコミットが完了したら、すべてのトランザクションリソースを解放します。
応答のフィードバックトランザクションが送信された後、 Ack応答をコーディネーターに送信します。
トランザクションの完了コーディネーターは、すべての参加者からACK応答を受け取った後でトランザクションを完了します。

別の状況は、コーディネーターが参加者によって送信されたACK応答を受信しない（受信者がACK応答を送信しない、または応答がタイムアウトする可能性がある）場合、コーディネーターは割り込み要求を送信し、すべての参加者に中止要求を送信します割り込みトランザクションが実行されます。

トランザクションのロールバックアボート要求を受け取った後、参加者はステージ2で記録された取り消し情報を使用してトランザクションのロールバック操作を実行し、ロールバックが完了した後にすべてのトランザクションリソースを解放します。
フィードバックの結果参加者がトランザクションのロールバックを完了すると、コーディネーターにACKメッセージを送信します
トランザクションの中断参加者からACKメッセージを受信した後、コーディネーターはトランザクションを中断します。

注： DoCommitフェーズでは、パーティシパントが時間内にコーディネーターからcommitまたはabortコマンドを受信できない場合、タイムアウトを待機した後もトランザクションをコミットし続けます。

引入超时提交的依据：実際、これは確率に基づいて決定する必要があります。3番目のステージに入るとき、参加者は2番目のステージでPreCommitリクエストを受信したことを意味します。コーディネーターがPreCommitリクエストを生成するための前提条件は、すべての参加者からのCanCommit応答はYesです。（参加者がPreCommitを受け取ったら、それは全員が実際にそれを変更することに同意することを意味します）つまり、参加者はコミットまたは中止応答を受け取らなかったが、ネットワークタイムアウトおよびその他の理由により、第3ステージに入るとき提出が成功する可能性が高いと信じるのには理由があります。

3PCの後半の2ステージは2PCに似ていますが、2PCがタイムアウトを待機した後にしかロールバックできず、タイムアウトを待機した後に3PCが送信できるのはなぜですか？その理由は、3PCが第2ステージに達したため、CanCommitの第1ステージに合格する必要があることを示し、全員が変更に同意することを示しています。3PCでは、誰もがトランザクション操作を実行することに同意します。2PCでは、反対に、全員が同意するか同意しないかを知りません。最初に問題を修正し、投票する前に同意しないかどうかを確認します。同意しない場合はどうなりますか？したがって、2PCはタイムアウト後にロールバックする必要があります。

2PCの場合、元に戻すおよびやり直しのトランザクションログは3PCの第2フェーズでのみ書き込まれるため、同期のブロックが改善されます。さらに、3PCの第3フェーズコーディネーターは、例外またはネットワークタイムアウトが発生した場合にもコミットします。それはまだ2PCはで説明が存在するので、それは、避けることができません同步堵塞、单点故障、数据不一致、容错机制不完善等问题。その中で数据不一致、たとえば、ネットワーク上の理由により、コーディネーターによって送信された中止応答が参加者によって時間内に受信されなかったため、参加者はタイムアウトを待ってコミット操作を実行しました。このようにして、中止コマンドを受信してロールバックを実行する他の参加者間にデータの不整合があります。残りの3つの欠点ながら同步堵塞、单点故障、容错机制不完善同様の理由やその他の基本的な問題と2PCリード。