分散データベースにおける2PCの最適化についてお話しましょう

[[375525]]

この記事はWeChatの公開アカウント「jinjunzhu」から転載したもので、著者はjinjunzhuです。この記事を転載する場合はjinjunzhu公式アカウントまでご連絡ください。

単一データベースの時代では、データベース自体が ACID トランザクションをサポートします。開発者は、メソッドに @Transactional アノテーションを追加するだけでトランザクションを処理することもできます。とても簡単です。しかし、シャードデータベースと分散テーブルの時代では、従来のデータベースの ACID プロパティは単一のノードでしか機能せず、グローバルトランザクションを維持するにはグローバルトランザクションマネージャーが必要となり、非常に複雑になります。

分散トランザクションの分野では、グローバル トランザクションに最も一般的に使用されるガイド スキームは 2PC (2 フェーズ コミットとも呼ばれます) です。しかし、2PC にもいくつか欠点があります。今日は、分散データベースがこれらの欠陥をどのように最適化するかを見ていきます。

2 フェーズ コミット (2PC)

2 フェーズ コミット プロトコルには主に 2 つあります。 1 つはアプリケーション層の TCC です。たとえば、Alibaba の seata は TCC モデルを実装しています。このモデルの特徴は、各サービスが try/confirm/cancel の 3 つの実装を提供する必要があることです。これら 3 つの実装はビジネス コードに実装する必要があり、ビジネスへの影響が非常に大きくなります。

今日は、Jim Gray 氏によって最初に提案されたリソース指向の 2PC プロトコルを紹介します。トランザクション全体は、準備フェーズとコミット フェーズの 2 つのフェーズに分かれています。これら 2 つのフェーズは、コーディネーション ノードと DB リソース マネージャーが連携して完了します。

ここでも、古典的な電子商取引システムを例として取り上げます。システム全体は、注文、アカウント、在庫の 3 つのサービスに分かれています。顧客から購入リクエストを受け取った後、調整ノードは注文を生成する注文サービス、製品の支払いを差し引くアカウント サービス、および製品在庫を差し引く在庫サービスを調整する必要があります。これら 3 つのサービスのデータベースが異なるスライスにある場合、調整プロセスは次のようになります。

1.準備段階

調整ノードはすべてのサービスに準備要求を送信します。準備要求を受信した後、各サービスはローカル トランザクションを実行しようとしますが、実際にはローカル トランザクションをコミットしません。実行試行プロセスでは、リソースがロックされているかどうかなど、トランザクションを実行するための条件が満たされているかどうかがチェックされます。すべてのサービスが正常に実行を試行すると、次の図に示すように、調整ノードに「はい」が返されます。

2. コミット/ロールバックフェーズ

準備フェーズですべてのサービスが yes を返す場合、コーディネーション ノードは各サービスにコミット操作を実行するように通知し、その後、各サービスは実際にローカル トランザクションをコミットします。以下のように表示されます。

準備フェーズ中にサービスが no を返した場合、コーディネータ ノードはすべてのサービスにローカル トランザクションをロールバックするように通知する必要があります。

2PCには問題がある

上記では 2PC プロトコルの実行プロセスを簡単に分析しましたが、2PC の問題点は何でしょうか?

1. パフォーマンスの問題

ローカル トランザクションは準備フェーズでリソースをロックします。たとえば、アカウントサービスがアカウント xiaoming から 100 元を差し引く場合、まずアカウント xiaoming をロックする必要があります。このように、xiaoming アカウントを変更する必要がある他のトランザクションがある場合、前のトランザクションが完了するまで待機する必要があります。これにより、遅延が発生し、パフォーマンスが低下します。

2. 調整ノードの単一障害点

調整ノードは単一のノードです。障害が発生した場合、トランザクション全体がブロックされます。たとえば、準備プロセスは最初のフェーズで成功しましたが、調整ノードは 2 番目のフェーズでコミット コマンドを発行する前にクラッシュしました。すべてのサービス データ リソースがロックされ、後続のトランザクションは待機することしかできなくなります。

3. 矛盾したデータ

最初の段階の準備が成功したが、2 番目の段階のコミット中に調整ノードが在庫サービスに通知できなかった場合、注文が生成され、アカウントが差し引かれますが、在庫は差し引かれないのと同じになります。これにより、データの一貫性が失われます。

パーコレーターモデル

TiDB などの主流の NewSQL データベースでは、この問題を解決するために Percolator モデルを使用します。公式サイトのリンクは以下の通りです。

 https://pingcap.com/blog-cn/percolator-および-txn/

Percolator モデルは Google の論文から引用したものです。

 「分散トランザクションと通知を使用した大規模な増分処理」

原文は次のリンクからご覧いただけます。また、オンライン上には翻訳版も多数あります。

 https://www.cs.princeton.edu/courses/archive/fall10/cos597B/papers/percolator-osdi10.pdf

Percolator の前提は、ローカル トランザクションのデータベースが、mvcc とも呼ばれるマルチバージョン同時実行制御プロトコルをサポートしていることです。現在、MySQL や Oracle などの主流のデータベースがサポートされています。

a) 初期段階

上で述べた典型的な電子商取引の事例を見てみましょう。初期段階では、注文数量が 0、アカウント サービスが 1000、在庫サービスが 100 であると仮定します。顧客が注文すると、注文サービスは注文を 1 つ追加し、アカウント サービスは金額 100 を差し引き、在庫サービスは製品数量 1 を差し引きます。各スライスの初期データは次のとおりです。

「:」の前の部分はタイムスタンプまたはデータバージョンであり、その後の部分はデータ値です。これら 3 つのテーブルでは、最初のレコードには実際のデータではなく、実際のデータへのポインタが格納されます。たとえば、注文テーブルでは、バージョン 6 はバージョン 5 を指し、注文数量は 0 です。

b)準備段階

準備フェーズでは、調整ノードが各サービスに準備コマンドを送信し、3 つのテーブルがそれぞれ準備フェーズに入ります。準備フェーズでは、Percolator はマスター ロックの概念を定義します。各分散トランザクションでは、この場合の注文サービスのように、マスター ロックを取得できるサービスは 1 つだけです。次の表に示すように、他のサービスのロックはこのマスター ロックのポインターを指します。

準備フェーズでは、各サービスはログを書き込み、タイムスタンプに基づいてトランザクションのプライベート バージョンを記録するため、他のトランザクションはこれら 3 つのデータに対して操作を行うことはできません。

c) コミット段階

コミット フェーズでは、オーダー サービスがプライマリ ロックを持っているため、コーディネーション ノードはオーダー サービスとのみ通信する必要があります。つまり、コーディネーション ノードはプライマリ ロックを持つスライスとのみ通信します。データは次のとおりです。

この時点で、注文サービスのロックに加えて、バージョン 7 を指すバージョン 8 が追加されていることに気付きました。つまり、注文サービスにはプライベート バージョンがなくなりましたが、アカウント サービスと在庫サービスのプライベート バージョンはまだ残っています。 Percolator がユニークなのは、非同期スレッドを開始してアカウント サービスとインベントリ サービスを更新する点です。最終データは次のとおりです。

コーディネータ ノードは、成功または失敗のいずれの場合でも、プライマリ ロックを取得したスライスとのみ通信する必要があるため、コミット中にすべてのノードが成功しないことによって発生するデータの不整合を回避できます。

準備フェーズではログが記録されます。スライスがコミットに失敗した場合、ログに基づいて再度コミットできるため、データの最終的な一貫性が確保されます。

コーディネーション ノードがダウンした場合、非同期スレッドはリソースを解放できるため、単一障害点の通信障害によるリソースの解放不能を回避できます。

ここでは2つの点に注意する必要があります。

• プライマリロックの選択はランダムに行われます。たとえば、この例では、注文サービスが選択されていない可能性があります。
• コーディネーション ノードがコミットを送信した後、最初に注文サービスが正常に送信されます。このとき、他のトランザクションがアカウント サービスと在庫サービスから 2 つのデータを読み取る場合、2 つのデータにはまだロックがかかっていますが、[email protected] を検索して送信済みであることを確認し、読み取ることができます。

要約する

2PC プロトコルには、パフォーマンスの問題、単一点障害、データの不整合という 3 つの問題があります。

Percolator モデルは、コーディネーション ノードとスライス間の通信プロセスを簡素化し、コーディネーション ノードがプライマリ スライスの 1 つとのみ通信できるようにします。一方で、通信オーバーヘッドが削減され、他方では、コミットフェーズ中に単一点障害や一部のノードの通信障害によって発生するデータの不整合が回避されます。

Percolator は準備フェーズでログを記録するため、コーディネーション ノードに障害が発生した場合でも、復旧後のログに基づいてトランザクションを復旧できます。

Percolator は非同期スレッドを使用してリソースを解放するため、コーディネーション ノードに障害が発生しても、リソースが解放されないことを心配する必要はありません。

よく知られている NewSQL データベース TiDB は、Percolator モデルに基づいて 2PC プロトコルを最適化します。

しかし、2PC のパフォーマンスの問題が依然として存在することを認識する必要があります。幸いなことに、主流の分散データベースは最適化されており、パフォーマンスの低下はますます小さくなるばかりです。