分散システムにおける CAP 理論

記事ディレクトリ

        I.はじめに

CAP理論とは?

        二、自然

2.1 一貫性(データの一貫性)

2.2 可用性 

2.3 パーティショントレランス(partition tolerance)

        3.CAPの選び方

        4. CAP に関する一般的な誤解

        5.CAPの不足


I.はじめに

CAP理論とは?

CAP 理論は、分散システムでは、一貫性、可用性、分断許容度の 3 つの項目のうち、最大 2 つの項目を同時に満たすことができることを意味します。CAP 理論は、分散システムにおける最も基本的かつ重要な理論です。


二、自然

2.1 一貫性(データの一貫性)

データの均一性を保つために、データは一緒に変更されます。分散ノードに格納されているデータ コンテンツが一貫していることを確認します。

データはいつ変更されますか?

データを含むサービスが更新要求を受信した場合にのみ、データが変更されます。データ更新要求には、データの追加、削除、変更の 3 つの要求のみが含まれ、これら 3 つの要求をまとめて書き込み要求と呼びます。したがって、データは書き込み要求が行われたときにのみ変更されます。

データはどのように一緒に変化すると言えますか? データの変更が一貫しているかどうかは、読み取り要求で確認する必要がありますが、読み取り要求の判断基準は何ですか?

分散システムに 2 つのノードがあり、各ノードに変更が必要なデータが含まれているとします。書き込み要求の後、両方のノードでデータが変更された場合。次に、読み取り要求は変更されたすべてのデータを読み取ります。このデータ変更を一貫したデータ変更と呼びます。

ただし、これはまだ完全な一貫性ではありません。システムは永遠に正常に動作することはできないからです。システムのノードが一貫した変更を受けられない原因となる問題がシステム内にある場合はどうなりますか? これを行うと、最新のデータを表示したい読み取り要求は、古いデータを表示するか、別のバージョンのデータを取得する可能性が高いことを意味します。現時点では、分散システムの外部データの一貫性を確保するために、データを返さないことを選択しています。 

意識しなければならないのは

        CAP 理論はある状態での選択について話しているものであり、実際の工学理論とは異なります。CAP 定理は主に状態を記述します。CAP 自体は状態に基づいており、過渡状態に基づいており、記述的な理論であり、エンジニアリングの問題を解決するものではありません。CAP は工学理論ではなく学術理論を本にしているので、多くのことを破棄します。

2.2 可用性 

CAP での可用性は、結果の要件です。システム内のノードは、受信した要求が書き込み要求であろうと読み取り要求であろうと、処理して応答できる必要があります。満たす必要がある2つの条件が必要なだけです。

条件 1: 返された結果が妥当な時間範囲内であること この妥当な時間はビジネスによって決定されます。ビジネスでは、100 ミリ秒以内に返さなければならないと言っています。妥当な時間は 100 ミリ秒で、1 秒以内に返す必要があります。つまり、1 秒です。ビジネスが 100 ミリ秒に設定されていて、結果が 1 秒で返される場合、システムはそうします。入手可能性を満たしていません。

条件 2: システム内の正常に要求を受け入れることができるすべてのノードが結果を返す必要があります。これには 2 つの意味があります。

  • ダウンタイムなど、ノードがリクエストを正常に受信できない場合、システムはクラッシュしますが、他のノードは引き続きリクエストを正常に受信でき、システムは引き続き使用可能です。つまり、部分的なダウンタイムは可用性インデックスに影響しません。
  • ノードがリクエストを正常に受信できるが、ノードの内部データに問題があることがわかった場合、返された結果に問題があっても、ノードは結果も返さなければなりません。たとえば、システムに 2 つのノードがあり、そのうちの 1 つには 3 日前のデータがあり、もう 1 つのノードには 2 分前のデータがあり、読み取り要求が 3 日前のデータを含むノードに送信された場合、ノードは 3 日前のデータを返す必要があります。合理的でない場合。

        可用性は、ユーザーが読んだときに何かを読めることを保証するだけで、ユーザーが読むものが最新であることを保証することはできません。ノードが他のノードから切断された場合、ローカル データが最新かどうかはわかりませんが、ユーザーの要求があればデータを直接返します。

2.3 パーティショントレランス(partition tolerance)

分散ストレージ システムには多数のノードがあり、これらのノードはネットワークを介して通信します。しかし、ネットワークの信頼性が低く、ノード間の通信に問題が発生した場合、現在の分散ストレージ システムにはパーティションが存在すると言われています。ただし、パーティションは必ずしもネットワーク障害が原因であるとは限らず、マシンの障害が原因である可能性があることに注意してください。

たとえば、分散ストレージ システムに 2 つのノード A と B があるとします。A と B の間でルーターやスイッチなどの一部の基盤となるネットワーク デバイスに障害が発生すると、A と B の間の通信の問題が発生します。これは、A と B の間のパーティションとも呼ばれます。A がダウンすると、A と B の間の通信にも問題が発生します。この状況は、A と B の間のパーティションとも呼ばれます。

要するに、分散システムである限り、ノード間の通信に問題があるとパーティションが発生します。つまり、パーティションの問題が発生した場合でも、分散ストレージ システム全体が稼働し続ける必要があります。パーティションの問題だけで、分散ノード全体の実行を停止することはできません。


3.CAPの選び方

この時点で、分散システムを設計するときに、C、A、および P の 3 つのプロパティのうち 2 つしか選択できないことがわかっています。

ただし、分散システムでは、P は避けられません。P を選択しないと、パーティション エラーが発生すると、分散システム全体がまったく使用できなくなります。したがって、分散システムの場合、パーティション エラーが発生した場合の一貫性と可用性を選択する方法しか考えられません。

一貫性と可用性の選択に応じて、オープンソースの分散システムは CP システムと AP システムに分けられることがよくあります。

システムでパーティション障害が発生すると、クライアントの要求はスタックまたはタイムアウトしますが、システム内の各ノードは常に一貫したデータを返します. そのようなシステムは、Zookeeper などの CP システムです.

システムにパーティション障害が発生した場合、クライアントは引き続きシステムにアクセスできますが、クライアントが取得するデータには新しいデータと古いデータが含まれる.このようなシステムは、Eureka などの AP システムです。

分散システムで内部問題が発生した場合、次の 2 つの選択肢があります。

  • 外部サービスへの対応
  • 外部サービスに対応してもらう

外部サービスを受け入れるということは、外部サービスの業務運営に自分たちの問題で影響を与えることができないということであり、可用性を優先する必要があります。外部サービスに対応するには、一貫性を優先する必要があります。


4. CAP に関する一般的な誤解

誤解 1: CAP 定理により、分散システムは C または A のいずれかをあきらめる

多くの人は、分散システムには可用性または一貫性しかなく、完全な可用性および一貫性機能はないと考えています。

P でこのような問題が発生する可能性は非常に低いため、パーティションの問題が発生する前に、システムは完全なデータの一貫性と可用性を備えている必要があります。

誤解 2: C と A の選択は分散システム全体のためのものであり、C と A の選択のみが全体として考えられる

パーティショニングが発生すると、一貫性と可用性の選択は、システム全体ではなく、実際にはローカルに行われます。

一部のサブシステムでいくつかの選択を行う場合もあれば、特定のイベントまたはデータの一貫性と可用性の選択を行う必要がある場合もあります。

分散システムの運用は何度も選択の連続であり、さまざまなイベントがさまざまな段階でさまざまな時期に発生する場合、まったく同じ選択肢を持つことは不可能です。

誤解 3: CAP の 3 つのプロパティには、範囲ではなく、yes と no の 2 つのオプションしかありません

CAP 理論の 3 つのプロパティは、ブール型ではなく、一貫性があるか一貫性がないか、使用可能か使用不可か、分割されているか分割されていないかということでもありません。むしろ、3 つのプロパティはすべて範囲型です。


5.CAPの不足

1. CAP定理自体はネットワーク遅延の問題を考慮しておらず、整合性はすぐに有効になると考えていますが、整合性を維持するには時間がかかるため、分散システムがAPシステムを選択することがよくあります。

2. 一貫性と可用性は、どちらか一方を選択するだけの問題ではなく、いくつかの重要な違いがあります. 一貫性が強調される場合、可用性が完全に利用できないという意味ではありません. 使いやすさが重視される場合、データの最終的な一貫性を確保するために、いくつかの技術的手段が使用されることがよくあります。

3. エンジニアリングの観点からは、CAP 理論は単なる状態の記述であり、何か問題が発生したときに分散システムがどのような状態になるかを人々に伝えます。しかし、状態は変化する可能性が高く、状態を切り替える方法、修復する方法、復元する方法については指示がありません。

おすすめ

転載: blog.csdn.net/HAOMINGS/article/details/127080688