分散システムの一貫性保証ソリューションの概要

導入

インターネットシステムでは、理想的には、システムが「一貫性」、「可用性」、および「パーティション耐性」を同時に満たすことが望まれます。しかし、よく知られている CAP 定理に基づいても、BASE 理論に基づいても、現実には実現不可能であることはわかっています。金融分野では、一貫性が最も重要な特徴であり、あらゆる状況で満たされなければなりません。この記事では、CAP定理とBASE理論については紹介しません。興味のある学生はBaiduで検索することができます。この記事では、強力な一貫性や最終的な一貫性など、一貫性を実現するためのソリューションに焦点を当てます。インターネット分野では、高可用性を実現するために強力な一貫性が犠牲になるケースが多くあります。多くの場合、最終的な時間がユーザーにとって許容可能な範囲内である限り、システムは「最終的な一貫性」を確保するだけで済みます。

[[204571]]

データベースのローカルトランザクション

データベース トランザクションは、間違いなく強力な一貫性ソリューションであり、一貫性がデータベース トランザクションによって保証され、ビジネス レイヤーが詳細を気にする必要がないため、最もシンプルな一貫性ソリューションでもあります。典型的な応用例はキャッシュバックのシナリオです。キャッシュバックのある取引の払い戻しの場合、2 つの取引注文を一度に払い戻す必要があり、これはローカル データベース トランザクションを通じて完了します。詳細は以下の通りです。

ユーザーAは100元を費やして販売者Bから商品を購入し、購入後に2元のキャッシュバックを受け取りました。これらは 2 つの取引で、元の取引は 100 元、キャッシュバック取引は 2 元です。その後、払い戻しが発生すると、両方の取引が同時に払い戻されるようにする必要があります。これは、ローカル データベース トランザクションを使用して直接実現されます。つまり、1 つの払い戻しリクエストと 2 つのトランザクションが同時に払い戻されます。

概要: データベース トランザクションの利点は、単純であり、ビジネス レイヤーがほとんど気にする必要がないことです。ただし、高可用性システムの場合、すべての操作がデータベース トランザクションで実行されると、トランザクションが非常に複雑になり、システムの拡張やメンテナンスに役立ちません。

2フェーズコミット

データベースはローカルの一貫性を確保できるだけでなく、インターネット システムはより分散化されたシステムです。分散システムについて話すとき、分散トランザクションについて言及する必要があります。分散トランザクションでは、2 フェーズ コミット プロトコル (2pc) を導入する必要があります。コアシステムでは、2 フェーズ コミット ソリューションは主に分散データベース NesioDB とトランザクション アカウント分離による柔軟なトランザクションで使用されます。

分散データベース NesioDB は、Baidu DBA と Baidu Wallet によって共同開発されました。分散トランザクションをサポートするデータベースです。 Baidu Walletのコア取引業務に適用され、2年間安定的に稼働しています。このデータベースの設計要件は、ユーザーが分散データベースをスタンドアロン データベースのように使用できるようにすることです。したがって、実装された分散トランザクションは、スタンドアロン トランザクションの ACID 原則を満たします。分散トランザクションの一貫性に関しては、それを実現するために 2 フェーズ コミット アプローチが採用されており、分散トランザクション モデルを満たしています。下の図の通りです。

最初の段階は準備段階です。

DTM はトランザクションに関係するすべての RM に通知し、各 RM に準備メッセージを送信します。メッセージを受信した後、RM は準備フェーズに入り、直接失敗を返すか、ローカル トランザクションを作成して実行し、ローカル トランザクション ログ (REDO ログと UNDO ログ) を書き込みますが、コミットは行いません (ここでは、コミット操作の最後のステップのうち、最も時間が短いステップのみが、第 2 フェーズでの実行のために保持されます)。

2 番目のフェーズはコミット/ロールバック フェーズです。

DTM は、RM 準備フェーズで失敗メッセージを受信した場合、または RM 戻りメッセージを取得するときにタイムアウトした場合は、RM に直接ロールバック メッセージを送信し、それ以外の場合はコミット メッセージを送信します。 RM は TM の指示に従ってコミットまたはロールバックを実行し、実行後にトランザクション処理で使用したすべてのロックを解除します (ロックは *** ステージで解除されます)。

データベース レベルでの 2 フェーズ コミットを使用すると、分散トランザクションの一貫性を確保できるため、ユーザーは分散トランザクションをスタンドアロン トランザクションと同じくらい便利に使用できます。 2 フェーズ コミットのもう 1 つの実装は、ビジネス レベルでの柔軟なトランザクションである TCC (Try-Confirm-Cancel) です。この柔軟なトランザクションを使用することで、トランザクションとアカウントの分離の一貫性が実現されます。まず、メインビジネス、スレーブビジネス、アクティビティマネージャー（コラボレーター）の 3 つのモジュールを含む柔軟なトランザクションについて説明します。

下の図は、柔軟な取引に関する典型的な図です。

*** フェーズ:メイン ビジネス サービスは、すべてのスレーブ ビジネス サービスの try 操作をそれぞれ呼び出し、すべてのスレーブ ビジネス サービスをアクティビティ マネージャーに記録します。ビジネス サービスからのすべての試行が成功するか、ビジネス サービスからの試行の 1 つが失敗すると、第 2 フェーズが開始されます。

フェーズ 2:アクティビティ マネージャーは、フェーズ 1 のビジネス サービスからの試行結果に基づいて確認またはキャンセル操作を実行します。最初の段階ですべてのスレーブ ビジネス サービスの試行が正常に完了した場合、コラボレーターはすべてのスレーブ ビジネス サービスの確認操作を呼び出し、それ以外の場合はすべてのスレーブ ビジネス サービスのキャンセル操作を呼び出します。

第 2 フェーズでは、確認とキャンセルも失敗する可能性があるため、データの一貫性を確保するために、これら 2 つの状況で例外処理が必要です。

1. 確認が失敗した場合: すべての確認操作をロールバックし、キャンセル操作を実行します。
2. キャンセルの失敗: ビジネス サービスは、キャンセルが確実に成功するように自動キャンセル メカニズムを提供する必要があります。

取引とアカウントを分離したプロジェクトに対応する場合、プロセスは次のようになります。

*** ステージ:メイン ビジネス サービスはトランザクションとアカウントを呼び出して、try 操作を実行します。トランザクションはトランザクションを開始し、ビジネス上の判断を行って書き込みますが、トランザクションをコミットしません。会計レベルでリソースをロックします。

フェーズ 2:アカウンティング リソースが正常にロックされ、トランザクションが正常に送信され、確認がアカウントに送信されます。トランザクションの送信に失敗した場合は、リソースを解放するためにキャンセルが送信されます。確認またはキャンセル中に例外が発生した場合は、データの一貫性を確保するために例外も処理する必要があります。

概要:この方法は実装がそれほど難しくなく、同じ方法で複数のデータベース操作が存在する従来の単一ボディ アプリケーションに適しています。

ロールバックメカニズム

分散アーキテクチャでは、関数 X はバックエンドで A、B、またはさらにアトミックなサービスを調整する必要があります。質問は、通話 A と B のいずれかが失敗した場合はどうなるかということです。この時点で、一貫性を確保するためにロールバック メカニズムを使用できます。このメカニズムは、ウォレットがクレジットと連携する共同融資プロジェクトで使用されます。次の図に示すように、このプロジェクトには合計 2 つのアトミック操作があります。

アトミック操作は、資金の回収とカードへの資金振替の 2 つです。いわゆる資金プーリングとは、加盟店 A と加盟店 B の資金を仲介業者 C にプールすることです。資金がカードに振り込まれると、仲介業者 C からの資金が銀行システムを通じてユーザー D の銀行カードに振り込まれます。これら 2 つの操作は一貫している必要があります。つまり、資金が正常に収集され、その後資金がユーザーのカードに正常に送金される必要があります。または、販売店 A と B の金額が変更されておらず、資金がカードに転送されない場合があります。つまり、資金は中間業者 C に留まることはできません。

このような状況に対応するために、ロールバック メカニズムを使用して、強力なロールバック操作を提供し、上記の一貫性を実現します。たとえば、資金の回収は成功したが資金がカードに到着しなかった場合、回収された資金の操作はロールバックされ、つまり資金は中間加盟店 C から加盟店 A と B にそれぞれ返されます。

概要: この方法には多くの欠点があり、ロールバックが非常に簡単で、依存するサービスが非常に少ない非常に単純なシナリオでない限り、複雑なシナリオでは通常推奨されません。この実装方法では、コード量が膨大になり、結合度が高くなります。また、簡単に元に戻せない事業も多数あるため、非常に制限があります。シリアルサービスが多数ある場合、ロールバックのコストが高すぎます。

ローカルメッセージテーブル

この実装方法のアイデアは、実は eBay から生まれたもので、その後 Alipay などの企業のプロモーションを通じて業界で広く使用されるようになりました。基本的な設計の考え方は、リモート分散トランザクションを一連のローカル トランザクションに分割することです。パフォーマンスとデザインの優雅さを考慮しない場合は、リレーショナル データベースのテーブルを使用してこれを実現できます。ウォレット非中核業務の非同期変換プロジェクトでは、ローカルメッセージ方式が使用されます。プロジェクトの変革計画は次のとおりでした。

1. コアビジネスはリアルタイムでトランザクションテーブルに書き込まれます
2. ユーザーディメンションのトランザクションクエリテーブルに従って、非コアビジネスの非リアルタイム非同期書き込みトランザクションテーブル。

トランザクション テーブルはトランザクション ディメンションであり、ユーザーのクエリ パフォーマンスを満たすには、ユーザー ディメンションに基づいて同じトランザクション クエリ テーブルをバックアップしてコピーする必要があります。ビジネス属性の観点から見ると、トランザクション テーブルはコア ビジネスであり、トランザクション クエリ テーブルは非コア ビジネス (クエリ目的) です。実際には、トランザクション テーブルはコア データベースであり、クエリ テーブルは非コア データベースです。ただし、この 2 つは一貫している必要があります。メッセージが失われないメッセージ キューがあれば、このタイプの一貫性の保証は簡単に解決できます。そのようなメッセージ キューがない場合はどうなりますか?実際、この問題はローカル メッセージ テーブルを使用することで解決することもできます。

図に示すように、これはローカル メッセージ テーブルを使用して最終的な一貫性を維持するアプリケーションです。詳細は以下の通りです。

1. ビジネス A は、ローカル トランザクションとしてローカル メッセージとビジネス データを DB1 に書き込みます。
2. ビジネス A はローカル トランザクションの書き込みを完了すると、MQ にメッセージを送信します。
3. MQ はメッセージをビジネス B にプッシュし、ビジネス B はメッセージを実行して DB2 に書き込みます。
4. MQ ではメッセージが失われないことを保証できないため、メッセージが失われた場合は、ビジネス C を介して DB1 からメッセージを読み取り、RPC を介してビジネス B に送信して再実行する必要があります。

もちろん、DB1 のメッセージが消費されたかどうかを判断する方法は、DB2 のトランザクション実行結果によって判断できます。

概要: 上記の方法は非常に古典的な実装であり、基本的に分散トランザクションを回避し、「最終的な一貫性」を実現します。ただし、リレーショナル データベースにはスループットとパフォーマンスの点でボトルネックがあり、メッセージの頻繁な読み取りと書き込みはデータベースに負担をかけます。したがって、本当に同時実行性の高いシナリオでは、このソリューションにもボトルネックと制限が生じます。

補償メカニズム

補償メカニズムは分散システムで最も広く使用されています。ウォレット アプリケーションには、コア チェックアウトやカードによる支払いなど、さまざまなシナリオがあります。コアレジで、銀行に引き落としを依頼したところ、引き落としが成功した後、システム自体がクラッシュしました。このとき、注文処理プログラムとも呼ばれるバックグラウンド プログラムがこの種のプロセスの処理を開始し、途中で中断された元のプロセスを続行できるようにします。

一般に、成熟したシステムでは、高レベルのサービスとインターフェースの全体的な可用性は通常非常に高くなります。一部のビジネスで瞬間的なネットワーク障害や通話タイムアウトなどの問題が発生する場合、この補償メカニズムは実際に非常に効果的です。

要約する

この記事では、コア システムのいくつかの具体的な実践的なプロジェクトを通じて、分散システムの一貫性を確保する方法について説明します。各ソリューションには特定の特性とアプリケーション シナリオがあります。実際、分散システムにおけるトランザクションの一貫性は、それ自体が技術的な問題です。現時点では、すべてのシナリオに対応できるシンプルで完璧なソリューションは存在しません。具体的な決定は、さまざまなビジネス シナリオに基づいてユーザーが行う必要があります。