分散トランザクション

分散型トランザクション#

内容来自

極客時間コラム:《分散型技術原理とアルゴリズム解析》

再有人问你分布式事务，把这篇扔给他

分散型トランザクション及び二相コミット、三相コミットの理解

トランザクションとは、一連の操作を含む、境界のある作業シーケンスであり、明確な開始と終了のマークがあり、完全に実行されるか、完全に失敗してロールバックされる必要があります。分散型トランザクションは、分散システム内で実行されるトランザクションであり、複数のローカルトランザクションで構成されています。

トランザクションの基本特性`ACID`#

原子性（Atomicity）
一貫性（Consistency）
隔離性（Isolation）
永続性（Durability）

CAP と BASE 理論#

CAP#

一貫性 (Consistency): 特定のクライアントに対して、読み取り操作が最新の書き込み操作を返すこと。データが異なるノードに分散されている場合、あるノードでデータが更新された場合、他のノードがこの最新のデータを読み取れるならば、強い一貫性と呼ばれ、どこかのノードが読み取れない場合は分散不一致と呼ばれます。
可用性 (Availability)：故障していないノードが合理的な時間内に合理的な応答（エラーやタイムアウトの応答ではない）を返すこと。可用性の 2 つの重要な要素は、合理的な時間と合理的な応答です。合理的な時間とは、リクエストが無限にブロックされることができず、合理的な時間内に応答を返すべきことを指します。合理的な応答とは、システムが明確に結果を返し、その結果が正しいことを指します。ここでの正しさは、例えば 50 を返すべきであり、40 を返すべきではないということです。
分割耐性 (Partition tolerance): ネットワーク分割が発生した場合でも、システムが引き続き動作できること。例えば、クラスターに複数のマシンがあり、1 台のマシンでネットワークに問題が発生した場合でも、このクラスターは正常に動作し続けることができます。

CAP 理論は、分散システムが一貫性（C）、可用性（A）、分割耐性（P tolerance）の 3 つの基本的な要求を同時に満たすことは不可能であり、最大でそのうちの 2 つしか満たすことができないことを示しています。参考リンク：

BASE#

BASE 理論は基本的可用性（Basically Available）、ソフトステート（Soft State）、および最終的一貫性（Eventual Consistency）を含みます。

基本的可用性：分散システムが故障した場合に、一部の機能の可用性を損失することを許可します。例えば、特定の e コマースの 618 大促の際に、非コアリンクの機能をダウングレードすることがあります。
ソフトステート：柔軟なトランザクションでは、システムに中間状態が存在することを許可し、この中間状態がシステム全体の可用性に影響を与えないことを保証します。例えば、データベースの読み書き分離では、書き込みデータベースが読み取りデータベース（主データベースから従データベースへの同期）に同期する際に遅延が生じることがあり、これは柔軟な状態の一種です。
最終的一貫性：トランザクションの操作中に同期遅延などの問題により不一致が生じる可能性がありますが、最終的な状態ではデータが一貫していることを保証します。

BASE は、CAP の理論がネットワーク遅延を考慮していないのに対し、BASE ではソフトステートと最終的一貫性を用いて、遅延後の一貫性を保証します。BASE は ACID とは対照的であり、ACID の強い一貫性モデルとは完全に異なり、強い一貫性を犠牲にして可用性を得ることを許可し、データが一定期間不一致であることを許容しますが、最終的には一貫した状態に達します。

分散型トランザクションを実現する方法#

XA プロトコルに基づく二相コミットプロトコル方法；
三相コミットプロトコル方法；
TCC トランザクションメカニズム
ローカルメッセージテーブル
Saga トランザクション

その中で、XA プロトコルに基づく二相コミットプロトコル方法と三相コミットプロトコル方法は、強い一貫性を採用し、ACID に従い、メッセージに基づく最終的一貫性方法は、最終的一貫性を採用し、BASE 理論に従います。

1、XA プロトコルに基づく二相コミット方法 (2PC)#

XA は分散トランザクションを実現する原理であり、分散排他制御の集中型アルゴリズムに似ており、トランザクションマネージャーがコーディネーターとして機能し、各ローカルリソースのコミットとロールバックを担当します。

プロセス#

第一段階：トランザクションマネージャーがトランザクションに関与する各データベースに事前コミット (precommit) を要求し、コミット可能かどうかを反映します。

第二段階：トランザクションコーディネーターが各データベースにデータをコミットするか、またはロールバックするよう要求します。

欠点分析#

同期ブロッキング問題：二相コミットアルゴリズムの実行中、すべての参加ノードはトランザクションブロッキング型です。つまり、ローカルリソースマネージャーがクリティカルリソースを占有している場合、他のリソースマネージャーが同じクリティカルリソースにアクセスしようとすると、ブロック状態になります。
単一障害点問題：XA に基づく二相コミットアルゴリズムは集中型アルゴリズムに似ており、トランザクションマネージャーが故障すると、システム全体が停止状態になります。特にコミット段階では、トランザクションマネージャーが故障すると、リソースマネージャーはマネージャーからのメッセージを待っているため、トランザクションリソースをロックしたままになり、システム全体がブロックされます。
データ不一致問題：コミット段階で、コーディネーターが参加者に DoCommit リクエストを送信した後、部分的なネットワーク異常が発生したり、コミットリクエストを送信する過程でコーディネーターが故障した場合、一部の参加者のみがコミットリクエストを受信してコミット操作を実行し、他の未受信の参加者はトランザクションをコミットできなくなります。これにより、分散システム全体でデータ不一致の問題が発生します。

2、三相コミットプロトコル方法 (3PC)#

三相コミットプロトコル（Three-phase commit protocol、3PC）は、二相コミット（2PC）の改良版であり、三相コミットはタイムアウトメカニズムと準備段階を導入しています：

タイムアウトメカニズム：コーディネーターまたは参加者が指定された時間内に他のノードからの応答を受信しない場合、現在の状態に基づいてコミットまたはトランザクション全体を中止することを選択します。
準備段階：コミット段階の前に、予備コミット段階を追加します。予備コミット段階では、一部の不一致の状況を排除し、最終的なコミット前に各参加ノードの状態が一致していることを保証します。

プロセス#

3PC は 2PC のコミット段階を二つに分け、三相コミットプロトコルは CanCommit、PreCommit、DoCommit の 3 つの段階を持ちます。

CanCommit:
CanCommit 段階は 2PC の投票段階に似ており、コーディネーターが参加者にリクエスト操作（CanCommit リクエスト）を送信し、参加者がトランザクションコミット操作を実行できるかどうかを尋ね、参加者の応答を待ちます。参加者が CanCommit リクエストを受信した後、Yes と返信し、トランザクションを正常に実行できることを示します。そうでない場合は No と返信します。
PreCommit: コーディネーターは参加者の返信に基づいて PreCommit 操作を実行できるかどうかを決定します。
1. すべての参加者が「はい」と返信した場合、コーディネーターはトランザクションの予備実行を実行します。
2. 参加者のいずれかがコーディネーターに「いいえ」メッセージを送信した場合、またはタイムアウト後にコーディネーターが参加者の応答を受信しなかった場合、トランザクションを中断する操作を実行します。
DoCommit: DoCommit 段階では、PreCommit 段階でコーディネーターが送信したメッセージに基づいて、コミット段階またはトランザクション中断段階に入ります。

2PC との比較#

2PC に比べて、3PC はコーディネーターと参加者の両方にタイムアウト時間を設定しており、2PC はコーディネーターのみがタイムアウトメカニズムを持っています。これにより、参加者が長時間コーディネーターノードと通信できない（コーディネーターがダウンした）場合にリソースを解放できない問題を回避します。参加者自身がタイムアウトメカニズムを持っているため、タイムアウト後に自動的にローカルコミットを行い、リソースを解放します。このメカニズムは、トランザクションのブロック時間と範囲を側面から減少させます。
2PC の準備段階とコミット段階の間に、予備コミット段階（PreCommit）を追加することで、最終的なコミット段階の前に各参加ノードの状態が一致していることを保証するバッファ段階が設けられています。

3、TCC トランザクションメカニズム#

TCC（Try-Confirm-Cancel）は補償トランザクションとも呼ばれます。その核心的な考え方は、「各操作に対して、それに対応する確認と補償（取り消し操作）を登録すること」です。これは 3 つの操作に分かれています：

Try 段階：主にビジネスシステムの検査とリソースの予約を行います。
Confirm 段階：ビジネス操作の実行を確認します。
Cancel 段階：ビジネス操作の実行をキャンセルします。

適用シーン

強い隔離性と厳格な一貫性が要求されるビジネス活動
実行時間が短いビジネス

4、ローカルメッセージテーブル#

eBay の分散システムアーキテクチャにおいて、一貫性の問題を解決する核心的な考え方は、分散処理が必要なトランザクションをメッセージまたはログの方式で非同期に実行し、メッセージやログをローカルファイル、データベース、またはメッセージキューに保存し、ビジネスルールに従って失敗を再試行することです。参考：Base: An Acid Alternative

5、Saga トランザクション#

Saga は 30 年前にデータベース倫理で言及された概念です。その核心的な考え方は、長いトランザクションを複数のローカル短トランザクションに分割し、Saga トランザクションコーディネーターが調整します。正常に終了すれば正常に完了し、あるステップが失敗すれば、逆の順序で補償操作を一度呼び出します。

注意すべきは、saga モードでは隔離性を保証できないことです。なぜなら、リソースをロックしていないため、他のトランザクションが依然として現在のトランザクションを上書きまたは影響を与える可能性があるからです。これに対処するために、Huawei の解決策を参照し、ビジネスレイヤーからセッションとロックのメカニズムを追加してリソースの直列操作を保証することができます。また、ビジネスレイヤーで事前に資金を凍結する方法でこの部分のリソースを隔離し、ビジネス操作の過程で現在の状態をタイムリーに読み取ることで最新の更新を取得することも可能です。

具体的な例：Huawei の servicecomb を参照できます。

拡張#

硬直トランザクションと柔軟トランザクション#

硬直トランザクションは、ACID 原則に従い、強い一貫性を持ちます。例えば、データベーストランザクションです。
柔軟トランザクションは、実際には異なるビジネスシーンに応じて異なる方法を使用して最終的一貫性を実現することを意味します。つまり、ビジネスの特性に応じて部分的な妥協を行い、一定の時間内のデータ不一致を許容します。

要約すると、硬直トランザクションとは異なり、柔軟トランザクションは一定の時間内に異なるノードのデータ不一致を許可しますが、最終的には一致することを要求します。そして、柔軟トランザクションの最終的一貫性は、BASE 理論に従います。

Yige