Yige

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

内容来自

1. 極客時間コラム:《分散型技術原理とアルゴリズム解析》
2. 再有人问你分布式事务，把这篇扔给他
3. 分散型トランザクションおよび二段階コミット、三段階コミットの理解

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

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

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

CAP と BASE 理論#

CAP#

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

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

• CAP 予想
• CAP 証明

BASE#

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

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

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

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

1. XA プロトコルに基づく二段階コミットプロトコル方法；
2. 三段階コミットプロトコル方法；
3. TCC トランザクションメカニズム
4. ローカルメッセージテーブル
5. Saga トランザクション

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

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

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

プロセス#

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

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

欠点分析#

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

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

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

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

プロセス#

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

• 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）は補償トランザクションとも呼ばれ、その核心思想は「各操作に対して、その確認と補償（取り消し操作）を登録すること」です。これは三つの操作に分かれています：

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

適用シーン

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

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

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

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

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

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

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

拡張#

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

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

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

分散型排他制御と分散型トランザクションの関係#