分散シリーズの第 1 部: 分散一貫性!

[[436204]]

背景

インターネット時代と環境では、需要に迅速に対応し、システムのスループットを向上させるために、複雑なシステムとデータを分割するマイクロサービス変換が頻繁に実行されます。

このときの一貫性とは、アプリケーションシステムの一貫性やデータの一貫性など、分散サービスシステム間の弱い一貫性を指します。

実生活における一貫性の例:

銀行が振込を処理すると、あなたの口座の残高が差し引かれ、他の人の口座の残高が増加します。

あなたの口座残高の引き落としは成功したが、他の人の口座残高の増加が失敗した場合、あなたは資金を失うことになります。

一方、あなたの口座残高の引き落としが失敗し、他の人の口座残高の増加が成功した場合、銀行は資金を失い、補償金を支払う必要があります。

理論と実践的なソリューションの紹介を通じて、分散一貫性について学びましょう。

基本理論

酸

データの書き込みまたは更新のプロセスでは、トランザクションの正確性と信頼性を確保するために、データベース管理システム (DBMS) には、原子性、一貫性、分離性、および永続性という 4 つの特性が必要です。

データベースシステムでは、トランザクションとは、一連のデータベース操作で構成される完全な論理プロセスを指します。

たとえば、銀行振込の場合、元の口座から金額が差し引かれ、その金額が対象口座に追加されます。これら 2 つのデータベース操作の合計は完全な論理プロセスを構成し、分離することはできません。

このプロセスはトランザクションと呼ばれ、ACID プロパティを持ちます。

CAP理論

一貫性

分散環境における一貫性とは、データが複数のコピーにわたって一貫性を維持できるかどうかを指します。

一貫性の要件では、システムがデータの一貫性のある状態で更新操作を実行する場合、システムデータが一貫性のある状態のままであることを保証する必要があります。

可用性

可用性とは、システムによって提供されるサービスが常に利用可能であり、ユーザーからの各操作要求が常に限られた時間内に結果を返すことができることを意味します。

「限られた時間内」とは、ユーザーの操作要求に対して、システムが指定された時間内に対応する処理結果を返すことができる必要があることを意味します。この時間範囲を超えると、システムは使用不可とみなされます。
「結果を返す」は可用性のもう一つの非常に重要な指標です。システムは、ユーザーのリクエストの処理を完了した後、正常な応答結果を返す必要があります。

パーティション耐性

分散システムでネットワークパーティション障害が発生した場合でも、ネットワーク環境全体に障害が発生しない限り、一貫性と可用性を満たすサービスを外部に提供できる必要があります。

実際の状況

CAP 理論は、分散システムは同時に 2 つのポイントしか満たすことができず、3 つすべてを考慮することは不可能であることを証明しています。

C と A が満たされている場合、P は満たされますか?

C を満たすには、すべてのサーバーのデータが同じであること、つまりデータの同期が実現されている必要があります。同期には時間がかかりますか?もちろんそうです。マシンの数が増えるほど、同期時間は遅くなります。ここで問題が発生します。同時にAも満たします。つまり、同期時間を短くしたいのです。この場合、マシンの数が多すぎることはあり得ず、P を満たすことができません。

C と P が満たされている場合、A は満たされますか?

P を満たすには多くのサーバーが必要です。サーバーが 1,000 台あるとします。同時に、C を満たすということは、各マシン上のデータが同じであることを保証することを意味します。すると同期時間が非常に長くなります。この場合、ユーザーが各サーバーにアクセスした際に取得したデータが常に最新のものであるとは保証できません。最新のデータを取得したい場合は、すべての同期が完了するまで待つ必要があります。そうすれば、それを手に入れることができます。ただし、A では、必要なデータを短時間で取得できることが求められます。これは矛盾ではないでしょうか?したがって、ここでは A を満たすことはできません。

分散システムにとって、ネットワークの問題は避けられない異常な状況であるため、パーティションのフォールトトレランスは分散システムが直面し解決しなければならない問題となっています。

そのため、ビジネスの特性に応じて、C（一貫性）とA（可用性）のバランスをどのように取るかということにエネルギーを費やす必要がある場合が多くあります。

ベース理論

BASE は、Basically Available (基本的に利用可能)、Soft state (ソフト状態)、Eventually Consistent (最終的に一貫性がある) という 3 つのフレーズの略語です。

BASE 理論は、CAP における一貫性と可用性のトレードオフの結果です。これは、大規模インターネットシステムの分散実践の要約から生まれ、CAP定理に基づいて徐々に進化してきました。

BASE理論の核となる考え方は次のとおりです。

強力な一貫性を実現できない場合でも、各アプリケーションは独自のビジネス特性に基づいて、システムが最終的な一貫性を実現できるように適切な方法を採用できます。

次に、BASE の 3 つの要素を見てみましょう。

基本的に利用可能

基本的な可用性とは、分散システムで予期しない障害が発生した場合に、ある程度の可用性の損失が許容されることを意味します (これは、システムが使用できなくなることと同じではないことに注意してください)。

例えば：

応答時間の損失。通常、オンライン検索エンジンは 0.5 秒以内に該当するクエリ結果をユーザーに返す必要がありますが、障害により、クエリ結果の応答時間が 1 ～ 2 秒増加しました。
システム機能の損失: 通常の状況では、電子商取引の Web サイトで買い物をする場合、消費者はほぼすべての注文をスムーズに完了できます。ただし、ホリデーショッピングのピーク時には、消費者のショッピング行動が急増するため、ショッピングシステムの安定性を保護するために、一部の消費者がダウングレードページに誘導されることがあります。

ソフトステート

ソフト状態とは、システム内のデータが中間状態で存在することが許可され、中間状態の存在がシステム全体の可用性に影響を与えないと想定されることを意味します。つまり、システムでは、異なるノード上のデータコピー間のデータ同期のプロセスに遅延が許可されます。

最終的に一貫性

最終的な一貫性は、一定期間の同期の後にすべてのデータコピーが最終的に一貫した状態に到達できることを強調します。

したがって、最終的な一貫性の本質は、システムデータの強力な一貫性をリアルタイムで保証する必要はなく、最終的なデータの一貫性をシステムが保証する必要があることです。

一般的に、BASE 理論は、大規模で可用性が高く、スケーラブルな分散システムを対象としています。これは、従来のトランザクションの ACID 特性とは逆です。これは、ACID の強力な一貫性モデルとはまったく異なります。代わりに、強力な一貫性を犠牲にして可用性を獲得し、一定期間データの不整合を許容しますが、最終的には一貫した状態に到達します。

しかし同時に、実際の分散シナリオでは、さまざまなビジネスやコンポーネントがデータの一貫性に対してさまざまな要件を持っています。したがって、特定の分散システムアーキテクチャの設計プロセスでは、ACID 特性と BASE 理論が組み合わされることがよくあります。

分散コンセンサスプロトコル

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

フェーズ 1 (投票フェーズ):

コーディネーターノードは、すべての参加ノードにコミット操作を実行できるかどうかを問い合わせ、各参加ノードからの応答を待機し始めます。
参加ノードは、クエリが開始されるまでのすべてのトランザクション操作を実行し、元に戻すおよびやり直しの情報をログに書き込みます (注: 成功した場合、各参加者は実際にトランザクション操作を実行しています)。
各参加ノードは、コーディネーターノードによって開始されたクエリに応答します。参加ノードのトランザクション操作が実際に正常に実行された場合、「合意」メッセージを返します。
参加ノードのトランザクション操作が実際に失敗した場合、「中止」メッセージを返します。

第2段階（提出実行段階）：

コーディネーターノードがすべての参加ノードから「同意」応答を受信すると、次のようになります。

コーディネーターノードは、すべての参加ノードに「正式な提出」要求を送信します。

参加ノードは正式に操作を完了し、トランザクション全体にわたって占有されていたリソースを解放する。

参加ノードはコーディネーターノードに「完了」メッセージを送信します。

コーディネーターノードがすべての参加ノードから「完了」メッセージを受信すると、トランザクションが完了します。

問題点:

リソースは同期的にブロックされます

データ送信プロセス中、処理に関与するすべてのサーバーはブロックされた状態になります。他のスレッドがクリティカルセクションのリソースにアクセスする場合は、セッション要求がローカルで実行されるまで待機してから、クリティカルセクションのリソースを解放する必要があります。

したがって、2 フェーズコミットアルゴリズムを使用すると、並行プログラム実行の効率も低下します。

単一点問題

さらに、単一点の問題が発生する可能性もあります。単一ポイント問題は、単一ポイントサーバー障害問題とも呼ばれます。つまり、分散クラスタシステムのスケジューリングサーバーに障害が発生すると、コーディネータが不足するため、クラスタ全体で 2 フェーズコミットアルゴリズムを実行できなくなります。

単一ポイント問題は、2 フェーズコミットアルゴリズムの最大の欠点でもあります。したがって、2 フェーズコミットアルゴリズムを使用する場合、システムの安定性の要件を満たすために、通常、いくつかの改善が行われます。

コミットフェーズ中にデータの不整合が発生する

統計クラスター内のサーバーがトランザクション操作を実行できる場合、調整サーバーはトランザクション操作を処理するサーバーにコミット要求を送信します。

このプロセス中に 1 台または複数のサーバーでネットワーク障害が発生し、調整サーバーからの送信要求を受信できず、これらのサーバーが最終的なデータ変更を完了できない場合、分散クラスター全体でデータの不整合が発生します。

3 フェーズコミットプロトコル (3PC)

3 フェーズコミットは、実際には 2 フェーズアルゴリズムに基づいた最適化と改善です。

2 フェーズプロトコルでの同期ブロックなどの問題を解決するために、3 フェーズコミットプロトコルでは、コーディネータと参加者の両方にタイムアウトメカニズムを導入し、2 フェーズコミットプロトコルの最初のフェーズを、クエリ、リソースのロック、そして実際のコミットという 2 つのステップに分割します。

予防

フェーズ 3 に入った後、コーディネータに問題がある場合、またはコーディネータと参加者間のネットワークに障害が発生した場合、つまり、参加者がコーディネータからの DoCommit または中止要求を時間内に受信できない場合、この異常な状況では、参加者はタイムアウトを待機した後、トランザクションのコミットを継続します。

3フェーズコミットプロトコルの問題

参加者が PreCommit メッセージを受信した後、ネットワークが分割されると、コーディネータと一部の参加者はネットワーク上で正常に通信できなくなります。これらの参加者は依然としてトランザクションをコミットするため、必然的にデータの不整合が発生します。

TCC

2PC であっても 3PC であっても、粒度の大きなリソースロックの問題があります。

まず、ユーザーが電子商取引サイトで 1,000 元相当の商品を購入し、残高を使用して 800 元を支払い、赤い封筒を使用して 200 元を支払うというシナリオを想像してみましょう。

2PC でのプロセスを見てみましょう。

準備段階:

注文システムは注文記録を挿入しますが、送信しません
バランスシステムは800元を差し引き、レコードをロックし、やり直しと取り消しのログを書き込み、コミットしません。
赤い封筒システムは200元を差し引き、記録をロックし、やり直しと取り消しのログを書き込み、コミットしません。

コミットフェーズ:

注文システムが注文記録を送信する
バランスシステムが提出され、ロックが解除されました
赤い封筒システムの提出、ロック解除

なぜ大規模なリソースロックが発生するのでしょうか?

これは、準備段階でデータベースがユーザーの残高から 800 元を差し引くときに、分離性を維持するためにレコードをロックするためです。トランザクションがコミットされる前は、他のトランザクションはレコードにアクセスできなくなります。

しかし、実際には800元を予約するだけでよく、ユーザーの残高全体をロックする必要はありません。これは 2PC と 3PC の制限です。これらはリソース層プロトコルであり、より柔軟なリソースロック操作を提供できないためです。

この問題を解決するために、TCC が誕生しました。 TCC は本質的には 2 フェーズコミットプロトコルですが、JTA の 2 フェーズプロトコルとは異なり、サービス層プロトコルであるため、開発者はビジネスに応じてリソースロックの粒度を自由に制御できます。

まず、TCC プロトコルの動作プロセスを見てみましょう。

TCC は、トランザクション送信プロセスを try-confirm-cancel の 3 つの段階に分割します (実際、TCC は try、confirm、cancel の略です)。

試してみましょう: ビジネスチェックを完了し、ビジネスリソースを予約する
確認: 予約されたリソースを使用してビジネス操作を実行します (べき等性が保証される必要があります)
キャンセル: ビジネス操作をキャンセルし、予約されたリソースを解放します (べき等性を保証する必要があります)

プロセスは次のとおりです。

トランザクションイニシエーターは、トランザクションコーディネーターに対してトランザクション要求を開始します。トランザクションコーディネーターは、すべてのトランザクション参加者の try メソッドを呼び出して、リソースの予約を完了します。この時点では、実際に業務は実行されませんが、後で実行される特定の業務のためにリソースが予約されます。これで1つのステージが完了します。
参加者が try メソッドを使用してリソースを予約したときに、トランザクションコーディネーターがリソースが不足していることを検出すると、参加者の cancel メソッドを呼び出して、予約したリソースをロールバックします。呼び出しが失敗する可能性があり (たとえば、参加者はネットワーク上の理由により要求を受信しますが、トランザクションコーディネーターはネットワーク上の理由により受信を受信しません)、再試行するため、キャンセルメソッドではビジネス冪等性を実装する必要があることに注意してください。
トランザクションコーディネータは、すべての参加者の try メソッドが OK を返すことを検出した場合、リソースをチェックせずにすべての参加者の confirm メソッドを呼び出し、特定のビジネス操作を直接実行します。
コーディネーターがすべての参加者の確認方法が正常であると判断した場合、分散トランザクションは終了します。
コーディネーターは、一部の参加者の確認メソッドが失敗したこと、またはネットワーク上の理由により受信が受信されなかったことを検出した場合、再試行します。一定回数の再試行後に試行が失敗した場合、通常はトランザクション補正が実行されます。

支払いシナリオにおける TCC プロセスを見てみましょう。

操作を試す

tryX注文システムは支払い対象となる注文を作成します
tryYアカウント凍結赤い封筒200元
tryZ、800元の資金口座を凍結

操作の確認

confirmX 注文が更新され、支払いが完了しました
確認Y口座から200元を引き落とす赤い封筒
確認Zは基金口座から800元を差し引きます

操作をキャンセル

cancelX 注文処理例外、資金の赤い封筒が返送され、注文の支払いに失敗しました
キャンセルY 赤い封筒の凍結に失敗し、口座残高が返還され、注文の支払いが失敗しました
cancelZ 残高の凍結に失敗しました。アカウントの赤い封筒が返送され、注文の支払いに失敗しました

ご覧のとおり、本来のアカウントロックではなく凍結を使用しています（実際の運用では、凍結操作はデータベース削減操作+ログで実装できます）。このように、凍結操作後、トランザクションがコミットされる前に、他のトランザクションもアカウント残高を使用できるようになり、同時実行性が向上します。

要約すると、2 フェーズコミットプロトコルと比較して、TCC には次のような主な違いがあります。

2PC はリソース層に配置され、TCC はサービス層に配置されます。
2PC インターフェイスはサードパーティの製造元によって実装され、TCC インターフェイスは開発者によって実装されます。
TCC は、リソースロックの粒度をより柔軟に制御できます。
TCC はアプリケーションに対して非常に侵襲的です。ビジネスロジックの各ブランチでは、試行、確認、キャンセルの 3 つの操作を実装する必要があります。アプリケーションは非常に侵襲的であり、変換コストが高くなります。

たとえば、注文サービスには元々インターフェースが1つしかありませんでした

//コードステータスを変更する
注文クライアントのステータスを更新します。

これらは次の 3 つのインターフェースに分割する必要があります。

 orderClient.tryUpdateStatus();
 orderClient.confirmUpdateStatus();
 orderClient.cancelUpdateStatus();

現在、TCC にはいくつかの実装があります。

tcc トランザクション:
バイトTCC
スプリングクラウドレストTCC

結果整合性モード

キャッシュコヒーレンスモード

高同時実行システムの共通のコア要件は、数十億のデータを読み取る必要があることです。明らかに、リレーショナルデータベースは、高同時読み取り要件に対する最適なソリューションではありません。インターネットにおける従来のアプローチは、キャッシュを使用することです。

一般的なキャッシュ方法は、ローカルキャッシュと分散キャッシュに分けられます。パフォーマンス要件がそれほど高くない場合は、分散キャッシュが推奨されます。データのリアルタイム性と分散一貫性に対する要件がそれほど高くない場合は、ローカルキャッシュを使用できます。たとえば、異なるマシンの構成が短期間で異なっていても、一部の人員の構成が通常の業務フローに影響を与えることはありません。

データベースとキャッシュは、強い一貫性ではなく、弱い一貫性を維持するだけで済みます。一般的なキャッシュソリューションについては、次を参照してください: Meituan の面接の質問: キャッシュの一貫性、私はこのように答えました。

クエリモード

サービス操作では、操作実行のステータスを外部に出力するためのクエリインターフェイスを提供する必要があります。

サービス操作のユーザーは、インターフェイスを照会してサービス操作の実行ステータスを確認し、さまざまなステータスに応じてさまざまな処理操作を実行できます。

例えば：

スケジュールされたタスクは、生成される注文を監視し、グループメッセージを送信します。 RDはグループメッセージを受信し、注文の特定のステータスを照会して、システムに問題があるかどうか、手動による修復が必要かどうかを判断します。

補償モード

操作全体が異常な状態にある場合は、操作内の問題のあるサブ操作を修正する必要があります。そのためには、未完了のサブ操作を再実行したり、完了したサブ操作をキャンセルしたりする必要がある場合があります。修復により、分散システム全体の一貫性が保たれます。システムを最終的に一貫性のあるものにするための努力は補償と呼ばれます。

自動回復: プログラムは、不整合な環境に応じて、未完了の操作を続行するか、完了した操作をロールバックすることで、自動的に整合性を実現します。
通知操作: プログラムが自動的に回復できず、設計で矛盾したシナリオが考慮されている場合は、手動で障害を補正するための操作機能を提供できます。
通知技術: システムが自動的に応答できず、操作機能がない場合は、データベースの変更やコードの変更などの技術的な手段で解決する必要があります。これは最悪のシナリオです。

例えば：

生成される注文を監視した後、システムは自動的に受信メッセージをプッシュして、受信注文を再生成し、再試行します。システムが自動的に回復できない場合は、問題を特定して修復するためにRDアクセスが必要です。

非同期保証モード

非同期保証モードは補償モードの代表的な例です。ユーザーが応答時間に対して高い要件を持たない場合によく使用されます。通常、このような操作はメインプロセスから削除され、非同期的に処理されます。処理後、通知システムを通じてユーザーに結果が通知されます。このソリューションの最大の利点は、電子商取引システムにおける物流や配送、決済システムにおける請求や会計など、同時トラフィックのピークを軽減できることです。

実際には、実行される非同期操作はカプセル化されて永続的に保存され、その後、補償操作のために未完了のタスクを定期的に取得することによって、非同期保証モードが実装されます。タイミングシステムが十分に堅牢である限り、どのタスクも最終的には正常に実行されます。

例えば：

調達システムは予算をリリースして消費し、ログを同期的に記録します。その後、非同期およびスケジュールされたタスクの再試行を使用して、リリースと消費の成功を確認します。

通常校正モード

運用のメインプロセスでは、システム間の校正が行われます。その後、バッチ操作のステータスを非同期的に校正できます。矛盾した操作が見つかった場合は、補正が実行されます。補正動作は、補正モードでの補正動作と一致します。

定期的な校正を実現するための鍵は、分散システムが最初から最後まで一意の ID を持つ必要があることです。一般的に使用される一意のID生成スキーム

例えば：

財務側の照合システムは、決済データと業務文書データの整合性を定期的にチェックします。

信頼性の高いメッセージングモード

非同期操作の場合、メッセージキューを使用して呼び出し元と呼び出し先を切り離し、システムの応答速度を向上させ、ピーク除去の目的を達成できます。

メッセージキューの場合、信頼性の高いメッセージ配信とプロセッサの冪等性を確保するために特別な機能を構築する必要があります。

信頼性の高いメッセージ配信

メッセージを送信する前に、メッセージをデータベースに保存し、ステータスを保留としてマークしてから、メッセージを送信します。メッセージが正常に送信された場合は、メッセージを「送信成功」に変更します。スケジュールされたタスクは、一定期間内に送信されていないメッセージをデータベースから取得し、メッセージを送信します。

サードパーティのメッセージマネージャーを使用する場合は、メッセージを送信する前に、まずサードパーティのメッセージマネージャーに事前メッセージを送信します。メッセージマネージャーはそれをデータベースに保存し、ステータスを保留中としてマークします。送信が成功したら、メッセージを正常に送信されたものとしてマークします。スケジュールされたタスクは、一定期間内に送信されていないメッセージをデータベースから取得し、ビジネスシステムが送信を継続する必要があるかどうかを確認し、クエリ結果に基づいてメッセージのステータスを判断します。

メッセージプロセッサの冪等性

メッセージを確実に送信するには、再試行メカニズムが必要です。再試行メカニズムを使用すると、メッセージは確実に繰り返されるため、重複に対処する必要があります。一般的な解決策はいくつかあります。

データベーステーブルの一意のインデックスを使用して、重複したリクエストを防ぎ、重複したリクエストを拒否します。
重複防止のための分散ミドルウェアRedisの使用
重複を防ぐにはステートマシンを使用します。ドキュメント関連のビジネスにはステートマシンが関与し、さまざまな状況に応じてステートが変化します。ステートマシンがすでに次の状態にある場合、この時点で前の状態に変更することは理論的には不可能であり、これにより有限ステートマシンのべき等性が保証されます。
重複を防ぎ、条件付きでデータを更新するために楽観的ロックを使用します。これは、システムを設計する際の楽観的ロックの合理的な選択でもあります。更新がタイムリーに行われ、同時実行の際にあまり多くの問題が発生しないように、バージョンまたはその他の条件を使用して楽観的ロックを実行します。

例えば：

ドキュメントを保存するためのhttpインターフェースは、フロントエンドで送信するときに一意のIDを追加し、重複した注文の作成を防ぐためにRedisを使用して重複送信を防ぎます。

注文はMQ非同期インタラクションのインバウンドおよびアウトバウンドシステムに接続され、注文の中間状態を通じて再試行が実行され、下流は重複防止に使用されます。

<<: エッジコンピューティングとは何ですか? また、高等教育でどのように活用できますか?

>>: クラウドコンピューティングベンダーはアップグレードの転換点を迎えており、エッジコンピューティングの導入が決定的な要因となる可能性がある。