分散システムの一貫性の問題についてお話ししましょう。どれくらい知っていますか？

[[325065]]

0.前に書く

数日前、pyq に関する記事の募集を開始しました。分散一貫性の問題というトピックが最も注目を集めました。分散システムの内容は非常に複雑なので、いくつかの重要な部分から始めて、ゆっくりと拡張していきます。

今日は分散システムの一貫性の問題について学習することに焦点を当てますが、内容は比較的大きく、いくつかの部分に分けて記述する必要があります。

[[325066]]

1. 分散学習のメリット

バックエンドの専門家として、仕事を探したり履歴書を書いたりするときには、高並行性の経験に加えて、分散システムに精通している|理解している|習得している|熟練していることも書くことが多いため、高並行性と分散はほとんどの場合、ペアで登場します。

私はLagouでバックエンドのポジションを検索しました:

分散システムは貴重な知識ポイントです。今すぐ行動を起こしてみませんか。

2. エントロピーが増加する分散システム

分散システムとは何かを紹介する記事は数多くあります。実際、理解するのは難しくありません。簡単に言えば、工場の仕事を 1 人でこなせない場合は、一緒に働く労働者をさらに雇う必要があります。非常に多くの人が目標に向かって迅速かつ効率的に作業するには、何らかのルールとルーチンが必要です。そうでないと混乱が生じます。

実用的な観点から見ると、分散システムは重要なアーキテクチャ モデルです。インターネット エンジニアリング アーキテクチャの進化に関して、分散システムが登場する理由と分散システムとは何かについて簡単に説明します。

業務量が急増し、通常の単一マシンシステムでは要件を満たすことが困難になっています。マシンハードウェアの垂直拡張とアップグレード、または安価なサーバーの水平拡張とスタッキングのいずれかが主流のソリューションです。現在、インターネット分野では後者、つまり水平展開が選択されています。

ビジネスの成長に対応するために、マシンを水平方向に拡張し、複数のコンピュータルームを配置してサービスクラスターの規模をアップグレードすることで、分散システムの出現につながりました。これらの分散システム内の物理ノードは、複数のコンピュータ ルームや複数のネットワーク シナリオに展開され、ネットワークを介して相互に通信および連携することができます。

分散システムは膨大な業務量とデータ量を処理するように設計されていますが、多数のノードが連携して共通の目標を正確かつ秩序正しく達成するには、理論と実践の両方が必要であり、これも分散システムの焦点です。

一般的に、私たちがよく目にする分散システムには、分散ストレージと分散コンピューティングという 2 つのカテゴリがあります。

分散システム内の非常に多くのマシンが連携してタスクを完了するのは容易ではないため、通常、分散システムはエントロピーが増加するプロセスであると考えられています。

エントロピーは、システムの内部無秩序の度合いを表す物理量です。マクロ的なエントロピーを持つ孤立したシステムの場合、外部からの介入がなければ、システムの内部無秩序の度合いは増加し続け、つまりエントロピーが増加します。

システムを正常に保つためには、外部からの干渉を加える必要があります。分散システムの場合、システム全体を秩序正しく正しく保つために、対応する戦略とアルゴリズムを使用する必要があるため、分散システムはエントロピーが増加するプロセスであると考えられます。

これは理解するのが難しいことではありません。家をきれいに保つために定期的に掃除をしないと散らかってしまうのと同じです。

システムが制御および介入されなければ、システムは自ら混乱と無秩序へと向かうことになります。

3. 分散一貫性の問題の理解

分散一貫性とは正確には何でしょうか?

分散一貫性はさまざまな側面で現れますが、それらはすべて個別の問題です。ただし、個々の問題がいくつあっても、動作やステータスの表示はデータに基づいている必要があるため、これらの個々の一貫性の問題は、最終的には分散データの一貫性という共通の問題にマッピングされます。

分散システムには多くの独立したノードが存在します。一般的に、これらのノードはストレージとコンピューティングのタスクを独立して実行できます。これら 2 つが主なタスクの種類です。本質的には、コンピューティングとストレージのプロセスは依然としてデータを中心に展開されるため、データの一貫性が最終的な目標となります。

集中型構造では、管理ノードとタスクノードが区別され、各ノードの権利と義務が異なります。管理ノードは、下位ノードへのタスクの割り当てや計算結果の収集などを担当し、一般的にはコーディネーターの役割を担います。タスク ノードは主にタスクを実行するため、管理ノードの単一ポイントの問題に簡単につながる可能性があります。

分散型構造では、各ノードの権利と義務は同じです。指定されたリーダーは 1 人だけではありませんが、実際の操作には、リーダーの選出と、フェイルオーバー中のリーダーの動的な更新が含まれます。完全に分散化されたシステムは多くありません。集中型システムと比較すると、分散型システムはよりフラットで安定しています。公式の Redis クラスターは分散型の実装です。すべてのノードは同等であるため、いずれかのノードに障害が発生しても大きな問題は発生しません。

集中型または分散型の分散システムであっても、いずれかのノードの計算および保存結果は他のノードに影響を与えます。これらの独立したノードは、基本および特定のネットワーク プロトコルを通じて連携し、全体を形成します。

4. 厳格なデータ一貫性

ある程度の準備の後、重要な部分である分散システムにおけるデータの一貫性の問題を研究し始めます。

我々は合意に達する必要があります。厳密な意味での分散データの一貫性は存在しません。

なぜ存在しないのでしょうか?

分散システムでは、データ ストレージは複数のノードによってバックアップされ、通常は読み取りと書き込みに分かれています。クライアントがマスター データベースのエージェントを介してデータを書き込む場合、マスター ノードのデータを非常に短い時間でスレーブ ノードにコピーすることはできません。現時点では、他のクライアントが読み取るスレーブ データベースのデータはすべて古いデータです。

賢い読者は「瞬間」という言葉を理解できます。もちろん、相対性の範疇として考えることもできますし、物理的な観点から考えるとより理解しやすいかもしれません。

Redis マスター ノードとスレーブ ノード間のデータ レプリケーションを例に、同期レプリケーションと非同期レプリケーションのシナリオにおけるデータ一貫性の問題を見てみましょう。

一般的に、サービスの高可用性を確保するために、同期レプリケーションの遅延は保証できないため、マスターノードとスレーブノード間のデータレプリケーションは非同期になります。もちろん、一部のシナリオでは同期レプリケーションも使用されるため、全体的な遅延は保証されません。マスターが 1 つでスレーブが複数ある場合、同期レプリケーションの遅延は保証されません。

したがって、ここでは厳密な意味でのデータの一貫性について議論するのではなく、許容できると考えられる時間範囲内でのデータの一貫性の問題、つまり、私たち自身の環境の制約内でのデータの一貫性について研究します。

スタンドアロン システムの一貫性とトランザクションは比較的簡単に実現できます。分散システムでは、すべてのノード間のやり取りはネットワークを介して行われる必要があるため、ネットワークは不安定になりがちであり、大規模システム内の単一ノードの安定性も考慮する必要があります。

前の段落は読みにくいです。私が言いたいのは、単一マシン システムのデータ一貫性要件を分散システムにコピーしないでください、なぜなら両者の制約は異なるからです。分散システムの一貫性を単一マシン システムの一貫性にできるだけ近づけるために、合理的な分析を行う必要があります。

結局のところ、ソロバトルとチームバトルは違います。典型的な「天剣龍剣伝」では、張無忌は謝洵を救出するために少林寺に行こうとしますが、彼が出会った3人の少林寺の僧侶、杜阿、杜南、杜傑は数十年にわたって瞑想を続けています。彼ら3人が完璧の頂点に到達するのはあまりにも困難だ。これは優れた分散システムの頂点でもあります...

5. CAP理論とPACELC理論

CAP 理論は、一貫性、可用性、およびパーティション耐性の関係を説明するものであることがわかっています。

分散システムでは、ノードの物理的な分散やネットワークの安定性などの理由により、パーティション許容度 P が避けられません。したがって、分散システムは、分散ネットワーク内にパーティション P が存在するという前提で構築する必要があります。

P に基づいて、C と A のどちらかを選択します。もちろん、これは常に C と A のどちらかを選択しなければならないという意味ではありません。ネットワークが正常な場合は、C と A の両方を使用できます。さらに、各システムには異なる設計目標があり、より実用的な要件に基づいて選択を行う必要があります。

P は分散システム内に必ず存在します。システム設計の初期段階で、C と A のバランスを取り、選択する必要があります。通常の状況下で正しい結果を達成することは基本的な要件であり、異常な状況下でも正常に動作できることが設計の焦点です。

分散システムでは、PACELC 理論が CAP 理論の拡張であるため、CAP 理論ではなく PACELC 理論を使用する方が適切です。 PACELC 理論は簡単に言えば次のように表現されます。

パーティション (P) が存在する場合、分散システムは可用性 (A) と一貫性 (C) のバランスを取る必要があります。それ以外の場合 (E) システムがパーティション P なしで実行される場合、システムはレイテンシ (L) と一貫性 (C) のバランスを取る必要があります。

PACELC 理論は CAP 理論よりも分散システムに適しています。これは、ネットワーク パーティションと通常の状況との間のトレードオフの問題を完全に示しています。特に、一貫性 C を説明するために L 遅延係数を導入します。一貫性 C は、強い一貫性と弱い一貫性と呼ばれるものです。

言うまでもなく、強力な一貫性にはマスター スレーブ データの非常に高い一貫性が必要であり、通常、それを保証するために可用性が犠牲になります。弱い一貫性は、結果的一貫性/セッション一貫性/モノトニック読み取り一貫性/モノトニック書き込み一貫性などに分けられます。実用的な観点からは、弱い一貫性のうち結果的一貫性にのみ焦点を当てる必要があります。

6. 分布とBASE理論

ネットワークの安定性上の理由から、分散システムにおけるネットワーク分割は考慮しなければならない問題であることはわかっています。一般的なインターネットのシナリオでは、サービスの高可用性を確保するために最終的な一貫性を選択します。つまり、一定期間 L の間データの不整合を許容し、データの複製と同期後に最終的に一貫性を実現します。

分散システムの一貫性を理解するための重要な理論的基礎である BASE 理論を見てみましょう。

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

BA の基本的な可用性とは、システムがほとんどの時間利用可能であり、障害による可用性の部分的な損失を許容しながらも、コアの可用性が確保されることを意味します。

S ソフト状態とは、データ状態が常に一貫している必要はなく、中間状態の存在が許可され、システムの可用性に影響を与えないことを意味します。

E 最終的な一貫性とは、ソフト状態を前提として、一定期間が経過すると、データが最終的に一貫した状態に到達することを意味します。

7. CAP、BASE、ACIDの関係

CAP 理論は、分散システムにおける一貫性 C、可用性 A、およびパーティション許容度 P 間の制約を説明します。

BASE理論とACID理論は、CAP理論の3つの要素を選択および拒否した後の特定の状況として見ることができます。スタンドアロン システムや分散システムにも適用できます。 3 つの関係は図に示されています。