面接中に分散トランザクション（2PC、3PC、TCC）について質問されたとき、この説明に間違いはありません。

[[324758]]

チャタリング

私がこの業界に初めて参入し、Java を書き始めたとき、最初に関わったプロジェクトが State Grid のビジネス システムだったことを今でも覚えています。このシステムは研究開発に5億元を投じたと言われており、最盛期には研究開発人員が500人に達したこともあります。このプロジェクトでは、当時最も普及していたssh（Struts+Spring+Hibernate）フレームワークが採用されました。典型的な 3 層アーキテクチャ (コントローラー -> サービス -> DAO) は単純で粗雑なものでした。全員が書いたコードはすべて大きなプロジェクトに配置されました。プロジェクト ファイルのサイズが数百 MB に達しました。当時、コードの競合を解決することが最大の作業負荷でした。

しかし、ドラマチックだったのは、テスト当日に5人が同時にオンラインになり、プロジェクトが崩壊したことです。 。 。ああ！当事者Aがどれほど怒るかは想像もつかない。プロジェクトチーム全員の先祖は呪われています。

無駄なことを言ってしまいました。この件が頭から離れません。言わないと不幸を感じてしまいます。冗談として扱いましょう。さて、本題に入りましょう。

背景

数日前、ある後輩がWeChatの公開アカウントにメッセージを残し、インタビューが分散型取引の問題にかかっているので、分散型取引について話してほしいと頼んだ。最近では、マイクロサービス アーキテクチャ システムの普及に伴い、面接の質問も徐々にアップグレードされ始めています。初期のように、SSH フレームワークの知識やデータ構造について単純に質問するだけではありません。高同時実行性、高可用性、分散サービス管理、分散ファイルシステム、分散xxx、とにかく分散に関連するものなら何でも出題されます。プロジェクトで実際に使用されるかどうかは関係ありません。重要なのは、それを理解する必要があるということです。もう学ぶことができないような気がしていつも困っていませんか？

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

Baidu の分散トランザクションの定義を見てみましょう。分散トランザクションとは、参加者、トランザクションをサポートするサーバー、リソース サーバー、およびトランザクション マネージャーが異なる分散システムの異なるノードに配置されているトランザクションを指します。

え〜と読んでさらに混乱してしまいました。理解を助けるために簡単な絵を描いてみましょう。受注と在庫削減を例に挙げてみましょう。システムの業務量が非常に少ない場合、「ワンストップ」システムは既存の業務ニーズを完全に満たすことができます。すべてのビジネスがデータベースを共有し、注文プロセス全体では、1 つの方法と同じトランザクションでデータベースを操作するだけで済む場合があります。

この時点で、すべての操作は 1 つのトランザクションに含まれ、すべてがコミットされるか、すべてがロールバックされます。

絵は粗いが原理はそうではない

しかし、業務量が増大し続けると、次第に「ワンストップ」システムでは膨大なトラフィックに耐えられなくなり、データベースを異なるデータベースやテーブルに分割し、業務をサービスに分割（SOA）して、受注センター、ユーザーセンター、在庫センターを分離する必要が生じます。その結果、ビジネス間の分離が実現し、各ビジネスは独自のデータベースを維持し、データは RPC 呼び出しを通じてのみ交換できるようになります。

ユーザーが再度注文を行う際、注文の作成と在庫の減算を行うには、注文 DB と在庫 DB の両方に対して同時に操作を実行する必要があります。 2 段階の操作は同時に成功する必要があります。そうでないと、ビジネスに混乱が生じます。ただし、現時点では自社サービスのデータ整合性しか保証できず、他サービスの呼び出し操作が成功するかどうかは保証できません。したがって、注文プロセス全体のデータの一貫性を確保するには、分散トランザクションが介入する必要があります。

絵は粗いが原理はそうではない

分散トランザクションについて説明する前に、トランザクションの基本的な概念を思い出してみましょう。トランザクションはプログラム実行単位であり、その中ですべての操作が正常に実行されるか、失敗します。

トランザクションには 4 つの基本特性があり、これらはよく ACID と呼ばれます。

原子性: トランザクションは分割できない全体です。トランザクション内のすべての操作は、成功するか失敗するかのいずれかになります。

一貫性: タスクの実行前と実行後、データは状態間で一貫している必要があります (A が B に送金する場合、A がお金を差し引いても B が受け取らないということは起こりません)。

分離: 複数の同時トランザクションは互いに分離されており、相互に干渉することはできません。

耐久性: トランザクションが完了すると、データベースへの変更は永続的に保存され、ロールバックすることはできません。

上記の知識ポイントは、何度も言及される概念であり、面接では必ず覚えておく必要があります。

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

困難があるところには必ず解決方法がある。賢いプログラマーを困惑させるものは何もありません。

XA プロトコルは、データベース ベースの分散トランザクション プロトコルであり、トランザクション マネージャーとローカル リソース マネージャーの 2 つの部分に分かれています。グローバル スケジューラとして、トランザクション マネージャーは、各ローカル リソース マネージャーにコミットまたはロールバックするための統一されたコマンドを発行する役割を担います。 2 次コミット プロトコル (2PC) と 3 次コミット プロトコル (3PC) は、このプロトコルから派生したものです。現在、Oracle や Mysql などのデータベースは XA インターフェースを実装しています。

1. 2フェーズコミット（2PC）

名前が示すように、2 フェーズ コミットでは 2 段階での送信が必要です。最初の段階は準備段階 (投票段階) です。 2番目の段階は提出段階（実行段階）です。

上記の写真はインターネットから引用したものです。著作権侵害があった場合は削除いたしますのでご連絡ください。

2 段階提出 (2PC) の原則を簡単に説明するために、単一控除インベントリを例に挙げてみましょう。

前述したように、サービス指向アーキテクチャ (SOA) 以降では、注文プロセスで複数のサービスが使用され、各サービスが他のサービスの呼び出しの成功を保証できなくなります。このとき、さまざまなサービス（参加者）を調整するためのグローバルな役割（コーディネーター）が必要になります。

注文リクエストはコーディネータを介して送信され、コーディネータは各参加者に準備メッセージを送信し、ローカル データ スクリプトを実行しますが、トランザクションはコミットしません。

コーディネータが参加者から失敗メッセージまたはタイムアウトを受信した場合、各参加者にロールバックメッセージを直接送信します。それ以外の場合はコミット メッセージを送信します。参加者はコーディネータの指示に従ってコミットまたはロールバック操作を実行し、トランザクション処理中に占有されていたすべてのリソースを解放します。当然のことながら、2PC はすべての操作が成功または失敗することを保証します。

2フェーズコミット（2PC）の欠点

2 フェーズ コミットはアトミック操作を提供するように見えますが、重大な欠陥があります。

• ネットワークジッタによるデータの不整合: コーディネーターが第 2 フェーズで参加者にコミット コマンドを送信した後、この時点でネットワークジッタが発生すると、一部の参加者はコミット要求を受信して​​実行しますが、コミット要求を受信して​​いない他の参加者はトランザクションの送信を実行できません。これにより、分散システム全体でデータの不整合が発生します。
• タイムアウトによって発生する同期ブロッキングの問題: 2PC のすべての参加ノードはトランザクション ブロッキング タイプです。参加ノードで通信タイムアウトが発生すると、残りの参加者は受動的にブロックされ、リソースを占有して解放できなくなります。
• 単一障害点のリスク: コーディネータへの依存度が高いため、コーディネータに障害が発生すると、参加者は依然としてリソースをロックした状態になり、トランザクションのコミット操作を完了できなくなります。コーディネータが失敗した後に新しいコーディネータが再選されますが、前のコーディネータの失敗により参加者がブロックされるという問題は解決できません。

2. 3相コミット（3PC）

3 フェーズ コミット (3PC) は、2 フェーズ コミット (2PC) のアップグレードおよび最適化です。 3PC は、2PC の第 1 フェーズと第 2 フェーズに準備フェーズを挿入します。これにより、最終提出フェーズの前に各参加者のノードのステータスが一貫していることが保証されます。同時に、コーディネーターと参加者の両方にタイムアウト メカニズムが導入されます。参加者がさまざまな理由でコーディネータからコミット要求を受信しなかった場合、ローカル トランザクションをコミットし、ブロックして待機することはありません。これにより、2PC の単一点障害の問題は解決されますが、3PC では依然としてデータの一貫性の問題を根本的に解決することはできません。

上記の写真はインターネットから引用したものです。著作権侵害があった場合は削除いたしますのでご連絡ください。

3PCの3つのステージは、CanCommit、PreCommit、DoCommitです。

CanCommit: コーディネーターは、トランザクションのコミット操作を実行できるかどうかを確認するために、すべての参加者に CanCommit コマンドを送信します。すべての回答が「はい」の場合は、次の段階に進みます。

PreCommit: コーディネーターはすべての参加者に PreCommit コマンドを送信し、トランザクションを事前コミットできるかどうかを尋ねます。参加者は PreCommit 要求を受信した後、トランザクション操作を正常に実行した場合は Yes 応答を返し、最終コミット ステージに入ります。参加者がコーディネータに No 応答を送信するか、またはネットワーク タイムアウトのためにコーディネータが参加者からの応答を受信しない場合、コーディネータはすべての参加者に中止要求を送信し、参加者は中止コマンドを受け入れてトランザクションの実行を中断します。

DoCommit: 最初の 2 つの段階ですべての参加者が YES と応答すると、コーディネーターは参加者に DoCommit コマンドを送信して、トランザクションを正式にコミットします。コーディネータが参加者から ACK 応答を受信しない場合、トランザクションを中止するためにすべての参加者に中止要求コマンドを送信します。

3. 補償取引（TCC）

多くの初心者は、TCC、2PC、3PC の概念に常に混乱し、それらを区別することができません。実際、TCC は 2PC や 3PC と同様に、分散トランザクションを実装するためのソリューションにすぎません。

TCC (Try-Confirm-Cancel) は補償トランザクションとも呼ばれます。 TCCの考え方は2PCと非常に似ており、トランザクション処理フローも非常に似ています。ただし、2PC は DB レベルで適用されますが、TCC はアプリケーション レベルの 2PC として理解できるため、実装するにはビジネス ロジックを記述する必要があります。

TCC の中心的な考え方は、「各操作に対して、対応する確認 (Try) と補償 (Cancel) を登録する必要がある」というものです。

ワンボタンインベントリを見て、その 3 つの操作について説明しましょう。

試行フェーズ:

注文を行うときは、Try 操作を使用して在庫予約リソースを差し引きます。

確認段階:

業務オペレーションの実行を確認し、予約されたリソースのみに基づいて購入リクエストを開始します。

ステージをキャンセル:

関連するビジネスのいずれかがリソースの予約に失敗した場合、すべてのビジネス リソースの予約要求はキャンセルされます。

上記の写真はインターネットから引用したものです。著作権侵害があった場合は削除いたしますのでご連絡ください。

TCC の欠点:

• アプリケーションは非常に侵襲的です。TCC はビジネス レイヤーに基づいているため、各操作には、試行、確認、キャンセルの 3 つのインターフェイスが必要です。
• 開発が難しい: コード開発の量が多く、データの一貫性を確保するために、確認およびキャンセル インターフェイスでも冪等性を実装する必要があります。

要約する

2PC、3PC、TCC の概念について簡単に紹介しました。間違いがありましたら訂正してください。分散トランザクションは、面接で常に話題になっており、上級のシニア Java エンジニアにとっても必須の知識ポイントです。