分散キャップ定理と基底理論の簡単な分析!

  [[346602]]

導入

理論計算機科学において、CAP 定理 (ブリューワーの定理とも呼ばれる) は、分散コンピューティング システムが次の 3 つの条件を同時に満たすことは不可能であると述べています。

• 一貫性（すべてのノードが同じ最新のデータコピーにアクセスすることに相当）
• 可用性（各リクエストは正しい応答を得ることができますが、取得されたデータが最新のデータであるという保証はありません）
• パーティション耐性 (実際的には、パーティションは通信の時間制限に相当します。システムが時間制限内にデータの一貫性を達成できない場合、パーティションが発生し、現在の操作で C と A のどちらかを選択する必要があります)

定理によれば、分散システムは 3 つの条件のうち 2 つしか満たすことはできず、3 つすべてを満たすことはできません。 CAP 定理を理解する最も簡単な方法は、パーティションの両側に 2 つのノードがあると想像することです。少なくとも 1 つのノードが状態を更新できるようにすると、データの不整合が発生し、C プロパティが失われます。データの一貫性を確保するためにパーティションの片側のノードが使用不可に設定されている場合、プロパティ A は失われます。 2 つのノードが相互に通信できない場合、C と A の両方が保証され、プロパティ P が失われます。

この定義はあなたを混乱させますか?何度か読み返すと、少し理解が深まったように感じるでしょう。 CAP理論は非常に抽象的に聞こえます。この記事では、実際の例を使用して、わかりやすい言葉で CAP 理論の意味を説明します。

CAP短編小説

この話はとても面白いです。リンク https://zhuanlan.zhihu.com/p/265670196 をクリックしてご覧ください。または、クリックして元のテキストを読むこともできます。この小さな物語を読んだ後では、前述の定義を理解しやすくなると思います。

キャップトレードオフ

CAP 理論では、一貫性、可用性、分断耐性の 3 つの特性を同時に満たすことはできません。では、どのようにバランスをとるのでしょうか。

CAを選択し、Pを放棄する

この状況は分散システムでは基本的に不可能です。分散環境ではパーティショニングは避けられないため、P を放棄するということは分散システムを放棄しなければならないということであり、CAP 理論についてこれ以上議論する必要はありません。

CPを選択しAを放棄する

分散システムが可用性を実現できず、頻繁にクラッシュしたりサービスの提供を停止したりすると、過去の「WeMall データベース削除インシデント」と同様に、ユーザー エクスペリエンスは非常に悪くなります。すべてのデータが取得されるまで、外部へのサービスの提供は継続されません。この期間中のダウンタイムはどのくらい続き、販売者にどのくらいの損失が発生するのでしょうか。当社の一般的な CP 分散システムには、分散データベース (redis) や Zookeeper などがあり、システムの可用性を犠牲にして強力なデータ一貫性の確保を優先しています。

APを諦めてCを諦める

高可用性を確保し、パーティションを許可する場合は、一貫性を放棄する必要があります。ネットワークの問題が発生すると、ノード間の接続が失われる可能性があります。高可用性を確保するには、ユーザーがデータにアクセスしたときに即座に応答を得る必要があります。したがって、各ノードはローカル データを使用してのみサービスを提供できるため、グローバル データに不整合が生じます。現在、ほとんどのシナリオでは、一貫性を犠牲にして可用性が選択されます (最終的な一貫性を維持)。春節に紅包を手に取るときと同じように、いくらのお金を手に取ったかはすぐにはわかりませんが、しばらくしてからもう一度確認するように促されます。春節期間中にチケットを購入したとき、この高速列車にはまだスタンプが押されていることがはっきりとわかりましたが、認証コードを入力して乗客情報を送信すると、チケットがないと言われました。リストページに戻って列車を確認すると、まだチケットがあることが表示されました。これらのユーザーエクスペリエンスは少し不親切ですが、許容範囲内です。

まとめ

CAP に関しては、これより良い選択肢はありません。ビジネスシナリオに応じて選択し、自分に合ったものを選択するだけです。

基本理論

BASE: 完全な名前: 基本的に利用可能、ソフト状態、最終的に一貫性がある。これはeBayの建築家によって提案されました。ベース理論は、CAP における一貫性と可用性のトレードオフの結果です。これは、大規模なインターネット分散実践の要約から生まれ、CAP 定理に基づいて徐々に進化してきました。中心となる考え方は次のとおりです。

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

基本的に利用可能

基本的な可用性とは何ですか?基本的な可用性を確保するために、パフォーマンス (サービス応答時間) とエクスペリエンス (部分的な機能エクスペリエンス) を犠牲にします。パフォーマンスを犠牲にする: たとえば、製品を照会する場合、通常の応答時間は約 1 秒ですが、基本的に利用可能な場合は、応答時間は約 10 秒になります。体験の犠牲: たとえば、ダブルイレブンショッピングフェスティバル期間中、Taobao はコア機能 (注文、支払いなど) のみが利用可能であることを保証しますが、その他の非コア機能 (返品、住所変更など) はダウングレードされます。ダウングレードの詳細については、以前の記事「高同時実行システムの 3 つの優れたツールのうちのダウングレード」を参照してください。

ソフトステート

全体的な可用性に影響を与えずに中間状態を許可するということは、システムが複数の異なるノード上のデータ コピーでデータ遅延を許可することを意味します。

最終的な一貫性

上記で述べたソフト状態ですが、常にソフト状態であるわけではなく、時間制限があるはずです。期限後は、すべてのコピーでデータの一貫性が維持されることが保証される必要があります。これにより、最終的なデータの一貫性が実現されます。この時間制限は、ネットワークの遅延、システムの負荷、データ複製ソリューションの設計などの要因によって異なります。

システムは、他の新しい更新操作がない場合、データが最終的に一貫した状態に到達することを保証できるため、システムのデータにアクセスするすべてのクライアントは最終的に最新の値を取得します。

仕上げる

私の知識が限られているため、抜け漏れが必ずあるでしょう。間違いを見つけた場合は、メッセージを残して指摘していただければ修正いたします。

この記事はWeChatの公開アカウント「java Finance」から転載したものです。以下のQRコードからフォローできます。この記事を転載する場合は、Java Finance Public Account にお問い合わせください。