記事のディレクトリ
1.分散型のものの一般的なソリューション：
- 2PC两段提交协议
- 3PC三段提交协议(弥补两端提交协议缺点)
- TCC或者GTS(阿里)
- 消息中间件最终一致性
- 使用LCN解决分布式事物，理念“LCN并不生产事务,LCN只是本地事务的搬运工”。
2. 2フェーズ送信（2PC）
2フェーズコミットは2PCとも呼ばれます。2PCは非常に古典的な強力なコンセンサスであり、集中型のアトミックコミットプロトコルです。
ここで言及されている集中化は、合意に2つのタイプのノードがあることを意味します。1つは集中化されたコーディネーターノード（コーディネーター）とN個の参加者ノード（参加者）です。
2つの段階：最初の段階：投票阶段と2番目の提交/执行阶段段階：。
たとえば订单服务A、支付服务B発注書を発送するプロセスの成功に対して支払うために、支払いを依頼する必要があります。そうでない場合は、発注書の処理を失敗状態として行う必要があります。
次に、2PCステージがどのように処理されるかを見てください
2.1。最初の段階：投票段階
第一段階は主に3つのステップに分かれています
1）お問い合わせ
コーディネーターは、準備と呼ばれるトランザクション前処理要求をすべての参加者に送信し、各参加者の応答を待ち始めます。
2）現地の業務を行う
各参加ノードはローカルトランザクション操作を実行しますが、実行が完了した後、データベースのローカルトランザクションを実際に送信するのではなく、最初にコーディネーターに「ここで処理できます/ここで処理できません」と報告します。。
3）各参加者は、取引照会への回答をコーディネーターにフィードバックします。
参加者がトランザクション操作を正常に実行した場合、はい応答がコーディネーターにフィードバックされ、トランザクションを実行できることを示します。参加者がトランザクションを正常に実行しなかった場合、いいえ応答がコーディネーターにフィードバックされ、トランザクションを実行できません。
最初のステージが実行された後、2つの可能性があります。1.すべて「はい」を返します。2。1つ以上の「いいえ」を返します。
2.2。第2段階：提出/実行段階（成功したプロセス）
成功条件：すべての参加者が「はい」を返します。
第2段階は主に2つのステップに分かれています
1）すべての参加者がコーディネーターにフィードバックする情報が「はい」の場合、トランザクションのコミットが実行されます
コーディネーターは、すべての参加者ノードにコミット要求を送信します。
2）トランザクションコミット
参加者はコミット要求を受信すると、ローカルトランザクションのコミット操作を正式に実行し、コミットの完了後、トランザクションの実行全体で占有されていたトランザクションリソースを解放します。
2.3。第2段階：提出/実行段階（異常なプロセス）
異常な状態：参加者からのフィードバックコーディネーターへの応答がないか、タイムアウトを待った後、コーディネーターはまだすべての参加者からフィードバック応答を受信していません。
異常なプロセスの第2段階も2つのステップに分かれています
1）ロールバックリクエストを送信します
コーディネーターはすべての参加者ノードにRoollBackリクエストを送信します。
2）トランザクションのロールバック
参加者がRoollBackリクエストを受信すると、ローカルトランザクションがロールバックされます。
4. 2PCのデメリット
上記のデモンストレーションを通じて、2PCに起因する欠陥を簡単に考えることができます。
1）パフォーマンスの問題
第1フェーズまたは第2フェーズのどちらのプロセスでも、すべての参加者リソースとコーディネーターリソースがロックされます。すべてのノードの準備ができた場合にのみ、トランザクションコーディネーターはグローバルコミットを通知します。
参加者がローカルトランザクションをコミットするまで、リソースは解放されません。このようなプロセスは比較的長く、パフォーマンスに大きな影響を与えます。
2）単一ノードの障害
コーディネーターの重要性のため、コーディネーターが失敗すると。参加者は永久にブロックされます。特に第2段階では、コーディネーターが失敗した場合、すべての参加者はまだ
トランザクションリソースの状態がロックされており、トランザクション操作を完了できません。（コーディネーターは電話を切りますが、コーディネーターを再選することはできますが、コーディネーターのダウンタイムのために参加者がブロック状態になっているという問題を解決することはできません）
2PCでのシングルポイント問題の3つのケース
（1）コーディネーターは正常で、参加者はダウンしています
コーディネーターはすべての参加者からフィードバックを収集できるわけではないため、ブロック状態に陥ります。
解決策：タイムアウトメカニズムを導入します。コーディネーターが指定された時間以上参加者からフィードバックを受信しなかった場合、トランザクションは失敗し、トランザクション終了要求がすべてのノードに送信されます。
（2）コーディネーターがダウンしていて、参加者は正常です
ステージに関係なく、コーディネーターのダウンタイムのため、送信リクエストを送信できず、操作を実行したが送信されなかったすべての参加者がブロックされます。
解決策：コーディネーターのバックアップを導入すると、コーディネーターは操作ログを記録する必要があります。コーディネーターが一定期間ダウンしていることが検出されると、コーディネーターのバックアップがコーディネーターを置き換え、操作ログを読み取り、すべての参加者に状態。
（3）コーディネーターと参加者の両方がダウンしている
第1段階で発生：第1段階では、すべての参加者が実際にコミットを実行しなかったため、残りの参加者からコーディネーターを再選出するだけで、新しいコーディネーターが第1段階と第2段階を再実行します。段階は問題ありません。 。
2）第2段階で電話を切った参加者は、電話を切る前にコーディネーターからの指示を受けませんでした。つまり、上記の4番目のステップがハングアップしているため、コーディネーターが4番目のステップを送信する前にハングアップした可能性があります。この場合、新しいコーディネーターは操作の第1フェーズと第2フェーズを再実行します。
3）それは第2段階で発生し、一部の参加者はすでにコミット操作を実行しています。ここと同じように、注文サービスAと支払いサービスBの両方が、コーディネーターから送信されたコミットメッセージを受信し、実際にローカルトランザクションコミットの実行を開始しましたが、予期しない状況では、Acommitが成功し、Bが実際にハングします。現時点では、データに一貫性がありません。彼はこの時点でコーディネーターと通信し、データを一貫性のあるものにする方法を見つけることができますが、彼のデータステータスはこの期間中すでに一貫性がありません！2PCはこの問題を解決できません。
3.三相提出（3PC）
3フェーズコミットプロトコル（3PC）は、主に2フェーズコミットプロトコルのブロッキングの問題を解決するためのものです。2pcの問題は、共同作業者が崩壊したときに、参加者が最終的な選択を行えないことです。したがって、参加者は、共同作業者が回復するまでブロックされたままになる可能性があります。3フェーズコミット（3フェーズコミット）は、2フェーズコミット（2PC）の改良版です。
2フェーズコミットとは異なり、3フェーズコミットには2つの変更があります。
1、 引入超时机制。同时在协调者和参与者中都引入超时机制。
2、在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的。
つまり、3PCは、タイムアウトメカニズムの導入に加えて、2PCの準備フェーズを再び2つに分割するため、3フェーズの送信にはCanCommit、PreCommit、およびDoCommitの3つのフェーズがあります。
3.1.CanCommitステージ
2PCの前の段階では、ローカルトランザクションの実行が完了した後、最終的にCommitは実行されず、他のサービスの実行が終了してYesが返され、実際にコミットが実行される前にコーディネーターによってコミットが発生しました。ここでのCanCommitは、データベースロックを取得する試みを指し、可能であれば、Yesを返します。
ステージは主に2つのステップに分かれています
トランザクションは、コーディネーターにCanCommit要求を参加者に送信するように要求します。トランザクションのコミット操作を実行できるかどうかを確認します。その後、参加者の応答を待ち始めました。
応答フィードバック参加者がCanCommit要求を受信した後、通常の状況では、トランザクションをスムーズに実行できると判断した場合、Yes応答を返し、準備完了状態になります。それ以外の場合はフィードバックいいえ
3.2。PreCommitステージ
フェーズ1では、すべての参加者が「はい」を返すと、トランザクションを事前コミットするために事前コミットフェーズに入ります。ここでのPreCommitフェーズは、コーディネーターと参加者の両方がタイムアウトメカニズムを導入していることを除いて、上記の最初のフェーズと同様です（2PCのコーディネーターのみがタイムアウトでき、参加者にはタイムアウトメカニズムがありません）。
3.3。DoCommitステージ
これは、2pcのフェーズ2に似ています。
4.まとめ
2PCと比較すると、3PCはコーディネーターとパーティシパントの両方にタイムアウト期間を設定しますが、2PCのコーディネーターのみがタイムアウトメカニズムを備えています。これはどのような問題を解決しますか？
この最適化ポイントは、主に、参加者がタイムアウトメカニズムを備えているため、参加者がコーディネーターノードと長時間通信できない場合（コーディネーターがハングアップした場合）にリソースを解放できないという問題を回避するためのものです。タイムアウト。
リソースを解放するための自動ローカルコミット。このメカニズムにより、トランザクション全体のブロック時間と範囲も削減されます。
さらに、CanCommit、PreCommit、およびDoCommitの3つのフェーズの設計を通じて、2PCと比較して、追加のバッファーフェーズが設定され、最終コミットフェーズの前に各参加ノードのステータスが一貫していることを確認します。
上記は2PCと比較した3PCの改善です（2PCの最初の2つの問題を比較的軽減します）が、3PCはまだデータの不整合の問題を完全には解決していません。
2PCと3PCを理解した後、2フェーズコミットも3フェーズコミットも分散整合性の問題を完全に解決できないことがわかります。GoogleChubbyの作者であるMikeBurrows氏は、コンセンサスプロトコルは1つだけであり、それがPaxosだと述べています。 、他のすべてのコンセンサスアルゴリズム。すべてPaxosアルゴリズムの不完全なバージョンです。