面接官は分散トランザクションについて尋ねましたが、彼は私に4万ドルを払いたいように感じました

[[374631]]

この記事はWeChat公式アカウント「小黒11:30」から転載したもので、著者は階下の小黒兄さんです。記事の転載については小黒11:30公式アカウントまでご連絡ください。

今回、分散トランザクションフレームワークを使用する中で、分散トランザクションに関する知識が少し身についたので、この記事では分散トランザクションについてお話ししたいと思います。まず、トランザクションとは何かを確認しましょう。

取引

トランザクションとは何ですか?バックエンド開発者として、日常の開発でデータベースを操作する限り、トランザクションを必ず使用します。ここで、トランザクションとは何かを説明するために、Wikipedia からの一節を引用します。

これは、データベース管理システムの実行プロセスにおける論理単位であり、有限の一連のデータベース操作で構成されます。

データベース システムにはトランザクション特性があり、これはファイル システムと区別する重要な機能です。従来のファイルシステムでは、ファイルの書き込み中にオペレーティング システムがクラッシュすると、ファイルが破損する可能性があります。データベース システムでは、データベースが確実にある状態から別の状態に変換されるように、トランザクション機能が導入されています。作業を送信するときに、すべての変更が保存されるか、まったく保存されないかを確認できます。

通常、トランザクションは複数の読み取り操作と書き込み操作で構成されます。

トランザクションには、一般に ACID と呼ばれる 4 つの基本プロパティがあります。

A (原子性): 原子性。取引は全体として扱われます。すべてのステートメントが成功するか、すべてが失敗します。一部のステートメントが成功し、一部のステートメントが失敗するという状況はあり得ません。

C (一貫性): 一貫性。データベースの状態は、ある状態から別の状態に変化します。データベース整合性制約は、トランザクションの開始前とトランザクションの終了後も変更されません。データベース整合性制約が変更されないというのはどういう意味ですか?たとえば、テーブルの名前フィールドが一意制約である場合、トランザクションがコミットまたはロールバックされた後に名前フィールドが一意でなくなると、データベース整合性制約が破壊されます。

I (Isolation): 隔離。複数の同時トランザクションは、互いに影響を与えることなく実行されます。

D（耐久性）：耐久性。トランザクションがコミットされると、データベースへの変更はデータベースに永続的に保存されます。したがって、この機能では、データベース システムがクラッシュしたときに復元でき、送信されたデータが失われないことが求められます。

そのため、初期の頃はシステムにはデータ ソースが 1 つしかなく、この時点ではデータベース システムのトランザクションに依存してビジネスの正確性を確保できました。

しかし、ビジネスが拡大し続けると、ビジネスの 1 つのテーブルに数千万のデータが含まれるようになる場合があります。データベース インスタンスを使用すると、パフォーマンスの問題が発生する可能性があります。今回はデータベースとテーブルの分割を検討します。ただし、これにより、単一のアプリケーションが複数のデータ ソースに接続する状況が発生する可能性があります。例については次の図を参照してください。

上記の購入プロセスでは、販売者の残高テーブルとユーザーの残高テーブルが 2 つの別々のデータベース インスタンスに存在します。このように、別のトランザクションによって、販売者残高またはユーザー残高の引き落としが成功するか失敗するかを確認できます。ただし、2 つのトランザクションが同時に成功または失敗するかどうかは保証できません。

別のケースでは、システムがどんどん大きくなるにつれて、システム アプリケーションを複数のマイクロサービスに分割し、単一のアプリケーションが 1 つのデータ ソースのみを操作するようにすることを選択します。このとき、次の図に示すように、1 つのビジネス コールが複数のアプリケーションを呼び出し、各アプリケーションが独立してデータ ソースを操作するという状況が発生します。

この場合、すべての呼び出しが成功することを保証することはできません。

上記の例から、ビジネスの発展に伴い、従来のスタンドアロン取引ではビジネスのニーズを満たせなくなったことがわかります。現時点では、それを保証するために分散トランザクションが必要です。

分散トランザクション

以下はWikiの説明からの抜粋です。

分散トランザクションは、2 つ以上のネットワーク ホストが関与するデータベース トランザクションです。

まず、分散トランザクションを実装するための理論的根拠について説明します。

分散トランザクション技術理論

CAP定理。分散システム (相互接続され、データを共有するノードの集合) では、読み取りおよび書き込み操作に関して、一貫性、可用性、およびパーティション耐性の 3 つのうち 2 つのみが保証され、残りの 1 つは犠牲にする必要があります。

Geek Time: Learning Architecture from Scratch 第22章の説明からの抜粋

CAP 理論では、3 つの要素のうち 2 つしか選択できないと定義されていますが、分散環境で考えると、ネットワーク自体が 100% 信頼できるわけではなく、障害が発生する可能性があるため、分割は避けられない現象であるため、P (分割許容度) 要素を選択する必要があることがわかります。 CA を選択して P を放棄した場合、分割が発生したときに C を確保するために、システムは書き込みを禁止する必要があります。書き込み要求があった場合、システムはエラーを返します (たとえば、現在のシステムでは書き込みが許可されていません)。これは、A ではエラーもタイムアウトも返されないことが必要であるため、A と競合します。したがって、分散システムでは CA アーキテクチャを選択することは理論的には不可能であり、CP または AP アーキテクチャのみを選択できます。

BASE理論とは、以下の3つの単語の略称です。

基本的に利用可能: 分散システムに障害が発生した場合、コア機能が利用可能であることを保証するために、利用可能な機能の一部が失われることが許容されます。

ソフト状態: システム内の中間状態の存在を許可しますが、システムの可用性には影響しません。ここでは、CAP の不一致について言及しています。

最終的に一貫性がある: 最終的に一貫性があるとは、一定期間が経過すると、すべてのノード データが一致することを意味します。

BASE は、CAP の AP ソリューションを補足するものです。 BASE では、遅延後の一貫性を確保するためにソフト ステートおよび結果整合性が使用されます。 BASE と ACID は反対です。 ACID は強力な一貫性モデルですが、BASE はこの強力な一貫性を犠牲にし、データが短期間不整合になっても最終的には一貫性が保たれるようになります。

次に、分散トランザクションの実装オプションを見てみましょう。

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

データベースリソースレベルに基づく

• 2PC 2フェーズコミットプロトコル
• 3PC 3相コミットプロトコル

ビジネスレベルに基づく

• TCC

データベース リソース レベルでの実装ソリューションに基づくと、複数のトランザクションが存在するため、各トランザクションのステータスを管理するロールが必要になります。この役割をコーディネーター、トランザクションの参加者を参加者と呼びます。参加者とコーディネータは通常、特定のプロトコルに基づいています。その中で最も有名なのは XA インターフェイス プロトコルです。コーディネーターと参加者の考えに基づいて、XA 分散トランザクションを実装するために 2PC と 3PC が提案されています。

2PC 2フェーズコミットプロトコル

名前が示すように、このプロセスは主に 2 つのステップに分かれています。

最初のフェーズでは、コーディネーター (トランザクション マネージャー) がトランザクションの事前コミットに関与し、その時点でデータベース リソースのロックが開始されます。参加者は、元に戻す操作とやり直し操作をトランザクション ログに書き込みます。第 2 フェーズでは、参加者 (リソース マネージャー) がトランザクションをコミットするか、UNDO ログを使用してトランザクションをロールバックし、リソースを解放します。

全体のプロセスを下の図に示します。

分散トランザクション送信の成功シナリオ:

分散トランザクションのロールバックシナリオ:

このソリューションの利点は、実装が比較的簡単で、主流のデータベースでサポートされ、一貫性が強いことです。 MySQL 5.5 以降は XA プロトコルに基づいています。

対応するソリューションにも欠点があります。

コーディネーターの単一点問題。送信フェーズ中にコーディネータがクラッシュすると、参加者は待機し続け、リソースがロックされ、継続的なブロックが発生します。コーディネーターは再選できますが、問題は解決できません。

同期ブロック時間が長すぎる場合、送信が完了してリソースが解放されるまで、トランザクション実行プロセス全体がブロックされます。参加者が提出プロセス/ロールバックプロセス中にネットワークの遅延により指示を受信できない場合、参加者はブロックされます。

データに矛盾があります。第 2 段階では、最初のコミット信号を送信した後にコーディネーターがクラッシュした場合、最初の参加者はトランザクションをコミットしますが、2 番目の参加者はコーディネーターの信号を受信しないため、トランザクションをコミットできません。

したがって、2PC の欠点を解決するために、改良されたソリューションである 3PC が提案されています。

3PC 3相コミットプロトコル

3 フェーズ コミットは、2 フェーズ コミットに基づいて 2 フェーズ コミットを改良したものです。 3段階の手順は次のとおりです。

1..CanCommit、コーディネーターは参加者にトランザクションをコミットできるかどうかを尋ねます。

2. PreCommit、すべての参加者がトランザクションをコミットできる場合、コーディネータは PreCommit コマンドを発行し、参加者はリソースをロックして、最終コマンドを待機します。

• すべての参加者は確認情報を返し、コーディネーターは各トランザクションにトランザクション実行通知を送信し、リソースをロックし、実行ステータスを返します。
• 一部の参加者が否定メッセージを返すか、コーディネーターがタイムアウトを待機します。この場合、コーディネータはトランザクションを正常に実行できないと判断し、割り込みコマンドを発行し、各参加者は準備状態を終了します。

3. コミットする。第 2 フェーズのすべての応答が ack の場合、トランザクションをコミットするために Do Commit が発行されます。それ以外の場合は、トランザクション中止コマンドが発行され、すべての参加者がトランザクションをロールバックします。

すべての参加者がトランザクションを通常どおり実行し、コーディネーターはロックされたリソースを解放するための最終コミット命令を発行します。

一部の参加者がトランザクションの実行に失敗し、コーディネーターはタイムアウトを待機し、ロックされたリソースを解放するためのロールバック命令を発行します。

詳細は下の図をご覧ください。

2 フェーズ コミットと比較して、3 フェーズ コミットでは、トランザクションのブロックを減らし、単一点障害を解決するためのタイムアウト メカニズムが導入されています。 3 番目の段階では、参加者がコーディネータの信号を受信できない場合、待機タイムアウト後、参加者はデフォルトでコミットを実行し、リソースを解放します。

3 段階のプロセスでは、依然としてデータの一貫性の問題を解決できません。コーディネータがロールバック コマンドを発行したが、ネットワークの問題により参加者が待機時間内にそれを受信できない場合、参加者はデフォルトでトランザクションをコミットしますが、他のトランザクションはロールバックされ、トランザクションの不整合が発生します。

TCC

TCC業務

トランザクション実行中の大規模なリソースロックの問題を解決するために、業界ではビジネスレベルのトランザクション定義に基づく新しいトランザクション モデルが提案されています。ロックの粒度はビジネス自体によって完全に制御されます。それは本質的に補償のアイデアです。トランザクション実行プロセスを「試行」と「確認/キャンセル」の 2 つの段階に分割します。各段階のロジックはビジネス コードによって制御されます。このようにして、トランザクションのロック粒度を完全に自由に制御できます。サービスは分離を犠牲にしてより高いパフォーマンスを実現できます。

TCC は Trying、Confirm、Cancel の略です。データベース レベルに基づく 2PC および 3PC とは異なり、TCC はアプリケーション レベルに基づいています。 TCC の 3 つのアクションは次のとおりです。

試しています:

• すべてのビジネスチェックを完了する（一貫性）
• 必要なビジネスリソースを確保する（準分離）

確認する：

• 本当にビジネスを実行する
• 操作が冪等性を満たしていることを確認する

キャンセル：

• トライフェーズで確保したビジネスリソースを解放する
• キャンセル操作は冪等性を満たす必要がある

上記の説明は最初は少しわかりにくいように聞こえるかもしれませんが、大丈夫です。実際のケースを使って説明します。

次に、ショッピングモールでの支払いプロセスをシミュレートします。ユーザーは、残金と紅包の支払いである合算支払いを使用して注文を行います。通常のプロセスは次のとおりです。

1. 注文を作成する
2. 注文する

• 残高システムを呼び出して残高を差し引く
• 赤い封筒システムを呼び出して赤い封筒の残高を差し引く
• 注文ステータスを支払済みに変更
• 完了後にお支払いください。
• 実際のプロセスは以下の図に示されています。

ただし、このような支払いプロセスでは複数のサブサービスが呼び出されるため、すべてのサービスが成功することを保証することはできません。たとえば、紅包を差し引くために紅包システムを呼び出せない場合があります。このとき、私たちは恥ずかしい状況に遭遇しました。レッドエンベロープサービスの障害により、メソッドが異常終了します。この時点では注文ステータスは初期ステータスですが、ユーザー残高は差し引かれています。これはユーザーエクスペリエンスにとって非常に不親切です。したがって、この支払いプロセス中は、このプロセスを全体的な動作として扱うメカニズムが必要であり、その中のサービス呼び出しが成功または失敗して、トランザクション全体になることを保証する必要があります。

この時点で、TCC トランザクションを導入し、注文プロセス全体をまとめて処理することができます。導入後、残高システム控除が失敗したため、注文システムと紅包システムをロールバックしました。全体のプロセスを下の図に示します。

残高システムの障害により、このプロセスでのすべての変更を元に戻す必要があるため、注文システムにキャンセル通知を送信し、赤い封筒システムにキャンセル通知を送信します。

したがって、システムが TCC トランザクションを導入した後は、呼び出しプロセスを変換する必要があります。

TCC取引をシステムに導入する方法

TCC トランザクションの 3 つのステップに従って、各サービスを Try Confirm Cancle の 3 つのステップに変換する必要があります。

TCC トライ:

上記の業務に応じて、注文システムは、注文ステータスをPAYINGに変更するtryメソッドを追加します。残高システムは、まず残高が十分かどうかを確認し、次に残高を差し引いて、差し引いた残高を凍結金額に追加する try メソッドを追加します。紅封筒システムはバランスシステムと同じです。変換プロセスからわかるように、TCC の try メソッドでは各ビジネス リソースをチェックする必要があり、このプロセスでは中間状態の導入が必要です。次の図に基づいて全体のプロセスを見てみましょう。

TCC 確認:

TCC ステップ 1 TRY すべてのサブサービス呼び出しが成功した場合、この時点で各サービスを確認する必要があります。各サービスに確認メソッドを追加します。例えば、残高方式の確認方法は凍結金額を0にする方法で、紅包方式は上記のようになります。注文システムは注文ステータスを SUCCESS に変更します。確認メソッドはべき等である必要があります。注文システムを更新する前に、まず注文ステータスが PAYING であることを確認してから注文を更新する必要があります。全体のプロセスを下の図に示します。

この時点で、さまざまなサービスを促進するために、TCC トランザクション フレームワークを使用する必要があります。 TCC トランザクション マネージャは、TRY メソッドが終了したことを感知すると、各サービスが提供する confirm メソッドを自動的に呼び出し、各サービスのステータスを最終状態に変更します。

TCC キャンセル:

TCC トライ プロセス中に凍結赤封筒方式が失敗した場合は、以前の変更をすべて元に戻し、初期状態に戻す必要があります。 cancle メソッドも、次に示す confirm メソッドのように冪等性を実装する必要があります。

これを見ると、TCC Try が成功した場合は confirm も必ず成功し、try が失敗した場合は cancel も必ず成功することが分かります。確認はシステムを最終状態に更新するための鍵となるからです。しかし、現実は残酷で、生産体制の確認や中止は必ず失敗する。このとき、確認呼び出しの結果を記録するには TCC フレームワークが必要です。確認呼び出しが失敗した場合、TCC フレームワークはそれを記録し、一定時間後に再度呼び出す必要があります。

要約と考察

全文を読んだ後は、分散トランザクションの基本的な理解が得られるはずです。

これを踏まえてまとめます。分散トランザクションを使用する場合は、実際のシナリオ アプリケーションと組み合わせる必要があります。

ビジネスがまだ初期段階にある場合は、迅速なオンライン反復を実現するためにデータベース トランザクションを選択できます。

ビジネスが一定の段階に達すると、システムが分割され始め、データベースも分割されます。ビジネスで一貫性を確保する必要がある場合は、分散トランザクションを使用する必要があります。分散トランザクションを使用する場合、業務に応じてどれを使用するかを検討する必要があります。

2PC または 3PC によって実装された分散フレームワークを使用すると、ビジネス アプリケーション層を変更する必要がなくなり、アクセスが比較的簡単になります。ただし、対応するエネルギー消費は比較的低く、データ リソースはより長い期間ロックされます。インターネットなどの同時実行性の高いビジネス シナリオには適していません。

TCC に基づく分散フレームワークは 2PC よりもパフォーマンスが高く、データの最終的な一貫性を保証できます。ただし、アプリケーション層では、1 つのメソッドを 3 つのメソッドに変換する必要があり、いくつかの中間状態をビジネスに導入する必要があります。相対的に言えば、アプリケーションの変換の程度は比較的大きいです。