CAP定理
Cap Principle
概要概要
CAP原則はCAPとも呼ばれますこの定理は、分散システムで、Consistency（一貫性）、Availability（可用性）、Partition tolerance（パーティションのフォールトトレランス）を参照します。3つは互換性がなく、せいぜい満たすことができるだけです。同時にそれらの1つ2 1。
-
一貫性（
Consistency）分散システム内のすべてのデータバックアップは同時に同じ値ですか？ （厳密な一貫性、すべてのノードが最新データの同じコピーにアクセスします）
-
可用性（
Availability）クラスター内の一部のノードに障害が発生した後、クラスター全体がクライアントの読み取りおよび書き込み要求に応答できるかどうか。 （データ更新の高可用性。取得したデータが最新のデータであることを保証するものではありませんが、最終的な一貫性を保証します）
-
パーティションのフォールトトレランス（
Partition tolerance）
分散システムでネットワークパーティションの障害が発生した場合でも、ネットワーク環境全体に障害が発生しない限り、一貫性と可用性を満たす外部サービスを提供できます。システムが制限時間内にデータの整合性を達成できない場合は、パーティションが発生したことを意味し、現在の操作は
Cである必要があります。Aでの中から選ぶ。
CAP定理の議論
基本シーン
CAPの基本的なシナリオでは、ネットワークに2つのノードN1とN2があります。 N1とN2はそれぞれ2台のコンピュータであり、それらの間のネットワークを接続できることが簡単に理解できます。 N1にはアプリケーションAとデータベースVがあります。また、N2にはアプリケーションB2とデータベースVがあります。ここで、AとBは分散システムの2つの部分であり、Vはデータストレージの2つのサブデータベースです。分散システムの。
- 整合性が満たされると、N1とN2のデータは同じになり、V0 = V0になります。
- 可用性が満たされると、ユーザーはN1またはN2のどちらを要求したかに関係なく、即座に応答を受け取ります。
- パーティションのフォールトトレランスを満たしている場合、N1とN2のいずれかがダウンしている場合、またはネットワークが利用できない場合、N1とN2の通常の動作には影響しません。
ネットワークは正常に動作しており、実際には同時にCAPを満たしています
ユーザーがN1マシンからのデータ更新を要求し、プログラムAがデータベースV0をV1に更新します。分散システムは、データMを同期し、V1をN2のV0と同期するため、N2のデータV0もV1に更新され、N2のデータはN2の要求に応答します。
- 一貫性：N1とN2のデータベースV間のデータが完全に同じであるかどうか。
- 可用性：N1とN2が外部要求に正常に応答できるかどうか。
- パーティションのフォールトトレランス：N1とN2の間のネットワークが相互運用可能かどうか。
ネットワークが異常であるため、CAPは同時に2つしか満たすことができません
]
N1とN2の間のネットワークが切断されたときに、ユーザーがデータ更新要求をN1に送信すると、N1のデータV0はV1に更新されます。ネットワークが切断されているため、分散システムはMを同期的に動作し、N2のデータはV0のままです。このとき、ユーザーはデータ読み取り要求をN2に送信します。データが同期されていないため、アプリケーションは最新のデータV1をユーザーにすぐに返すことはできません。私は何をすべきか？
ここには2つのオプションがあります。
- まず、データの整合性を犠牲にし、可用性を確保します。古いデータV0をユーザーに応答します。
- 2番目：可用性を犠牲にし、データの整合性を確保します。ブロックして、ネットワーク接続が復元され、データ更新操作Mが完了するまで待ちます。その後、ユーザーは最新のデータV1に応答します。
総括する
実際、分散システムの場合、そうではありませんCAPそのうちの1つだけを満たすことができます2ただし、ネットワークに問題がある場合：because P満たす必要があるので、AのみCで2つのうちの1つを選択してください。
トレードオフ戦略
なぜならCAPせいぜい満足できる2 1つは、トレードオフを行う必要があるためです。
-
PなしのCA
Pが不要な場合（パーティション化は許可されていません）、C（強い整合性）とA（可用性）が保証されます。ただし、Pを放棄するということは、システムのスケーラビリティを放棄することも意味します。つまり、分散ノードが制限され、子ノードを展開する方法がありません。これは、分散システム設計の本来の意図に反しています。従来のリレーショナルデータベースRDBMS：OracleとMySQLはCAです。
-
AなしのCP
A（使用可能）が不要な場合は、各要求がサーバー間で強力に一貫している必要があることを意味し、P（パーティション）により同期時間が無期限に延長されます（つまり、データ同期が完了するのを待ってから通常のアクセスが行われます）ネットワークが発生すると、メッセージの障害や損失などの状況では、ユーザーエクスペリエンスを犠牲にし、すべてのデータの整合性を待ってから、ユーザーにシステムへのアクセスを許可する必要があります。実際には、CPとして設計されたシステムが多数ありますが、最も一般的なシステムは、Redis、HBaseなどの分散データベースです。これらの分散データベースでは、データの整合性が最も基本的な要件です。リレーショナルデータベースを直接使用する方が適切であり、分散データベースを展開するためにリソースを浪費する必要はありません。
-
CなしのAP
高可用性とパーティショニングを可能にするには、一貫性を放棄する必要があります。パーティションが発生すると、ノードは接続を失う可能性があります。高可用性を実現するために、各ノードはローカルデータのみを使用してサービスを提供できます。これにより、グローバルデータに不整合が生じます。典型的なアプリケーションは、特定のメーターでの携帯電話のラッシュシーンのようなものです。このページでは、最初の数秒で製品を閲覧すると、在庫があることを確認するメッセージが表示されます。商品を選択して注文の準備をすると、注文が失敗し、商品が売り切れたというプロンプトが表示されます。 。これは実際には、最初にA（可用性）の観点からシステムの通常のサービスを保証し、次にデータの整合性の観点からいくつかの犠牲を払うことです。ユーザーエクスペリエンスにある程度影響を与えますが、ユーザーのショッピングプロセスを深刻に妨げることはありません。
主流の分散システムの選び方
| ユーレカ | 領事 | Zookeeper | ナコス | その他 | |
|---|---|---|---|---|---|
| キャップ | AP | CP | CP | AP / CP | CP |
| コンセンサスアルゴリズム | しない | ラフト | ZAB（PAXOSのようなプロトコル） | ラフト | ラフト |
for AP実際、コンセンサスアルゴリズムを気にする必要はないので、Eureka Serverを保証するために強力なデータ整合性アルゴリズムを使用しませんデータには一貫性があり、レジストリデータの最終的な一貫性は、データのコピーによってのみ達成されます。
そして好きZookeeperこのような分散調整コンポーネントの場合、データの整合性が最も基本的な要件です。したがって、極端な環境では、ZooKeeper一部のリクエストは破棄される可能性があり、結果を取得するためにコンシューマプログラムは再リクエストする必要があり、データの一貫性も確保する必要があります。
For Nacos言う、実現AP同時に、コンセンサスアルゴリズムも使用されますRaft 、 NacosはどのようにしてAPとCPを同時に実現しますか 。
参考文献
分散システムの場合。P基本的な要件ですCAP 3つのうち、CAのみ2つの間でトレードオフを行い、改善するためにあらゆる手段を試してくださいP 。
場合によっては、AP対CPこれらの企業がどのように選択しているかがわかります。