分散システム（分散システム）はますます重要になってきている、大規模なサイトでは、ほとんどの場合、分散されています。
分散システムの最も困難は、各ノードの状態を同期する方法です。CAP定理は、この点で基本的な定理であり、分散システムを理解するための出発点れます。
分散システムの3つの指標
1.一貫性（整合性）
分散環境では、一貫性は同じ特性の複数のコピー間でデータを保持することができるかどうかを指します。すべてのデータのための分散システムにクライアントからの要求を読んで、または最新のデータを読み取るか、失敗します。データ項目の実装を成功させるための更新操作を行うことができる場合は、すべてのユーザーが、このようなシステムが強い整合性（または厳格な一貫性）を持っていると考えられていたことを、最新の値を読み取ることができます。
特徴：最新のデータを読み込む、または失敗し、重点は上のいずれかで正しくデータ。
2.可用性（アベイラビリティ）
可用性は、システムが提供するサービスを意味し、常に使用可能な状態であることが、また、各ユーザの要求の操作のため、常に時間の限られた期間、非応答エラーを取得できるようにする必要があります - しかし、最新のデータに取得したデータを保証するものではありません。
システムの安定性等が行われている三ヶ月9.4 9、即ちN、すなわちサービス・レベル・アグリーメントSLAと呼ばれる可用性の説明のために番号9、で99.9％、99.99％、。たとえば、私たちは、今月30日であれば、それは21.6分で、その99.95％毎月SLA、サービスの失敗毎月合計時間のわずか0.05％までの平均時間を言います
特徴：、データを返しますエラーを返しませんが、最新のデータを保証するものではありません、重点がある間違っていない読み書きする任意の時点で成功しています。
3.パーティショントレランス（パーティション公差）
ほとんどの分散システムは、複数のサブネットワークに分散されています。各サブネットワークは、ゾーン（パーティション）と呼ばれています。パーティション公差はトレラントネットワークシステムパーティションが表示されていること「メッセージの一部が失われるまたはパーティション障害が、分散システムが作動し続ける場合、ノードが発生する」を意味し、到達不能なネットワーク・ノードまたはネットワーク・パーティション間の出会いの場合下は、まだサービスの外部一貫性と可用性を満たすために提供することができます。
特長：私はいつも、私の内部の様子を同期強調がされたデータの種類に関係なく実行されますハングアップされていません。
分散システムでは、層分割システム以来、Pは、CAPアプリケーションモデルアーキテクチャは、CPとAPアーキテクチャで、決定されます。分散システムは、より良いAを達成し、方法、前提のPartitionToleranceであること、懸念しています...
第二に、CAP証明した理論
CAP証明論は、いくつかの方法は、これに反する証拠によって最も直感的です。定理を証明するCAPの矛盾は、最初リンチによって提案されたCAPは、同時に3を満たすことができる場合、それはCを保証することができないので、実用的なシナリオを介して、Pの存在を可能にすることにより、サーバー間のパケット損失が存在しなければなりません
スタンドアローンシステム
分散システム
同時に、「一貫性」、「可用性」と「パーティションのフォールトトレランス」3のCAPの法則を満たすことができない分散システムで見ることができます。
三、CAP理論の応用
CAP理論が私たちを連想させる、アーキテクチャ設計では、その選挙の3つだけ、数学上のCAP理論不可能三角形に似た、3つの完璧なシステムを満たすために、分散設計する方法については、しかし、合理的なトレードオフにエネルギーを無駄にしません第二に、すべては利用できません。
異なるビジネス要件の一貫性のために異なっています。マイクロブログにコメントの用語と親指アップの例では、矛盾のユーザーが敏感ではない、限り地元の対話を行うよう、比較的長い時間の矛盾を許容することができ、およびユーザーエクスペリエンスに影響を与えません。私たち電力供給のショッピング、製品の価格データをビジネスは即効性と価格を変更できない場合は、強い一貫性を必要とするとき、それはトランザクション成功率に非常に大きな影響を与えることになります。
、データはノード間で複製されなければならないときに、トランザクションのコミットには時間がかかり、CAP理論があること、ネットワークの遅延を無視することで、注意すべきです。現実には、リアルタイムのネットワークではないので、時間の矛盾の一定量が常に存在するためであっても、ノードBにノードAから同じ部屋をコピーします。
四、BASE理論
BASEの意味論は、我々はパートAとCを達成することができ、AまたはCの間で選択する必要がないことです
BASEは、（利用可能な塩基性）、略語3つのフレーズソフト状態（ソフト状態）、最終的に一貫性のある（最終的な一貫性）は、基本的に入手可能であり、CAPは、APの拡張です。
1.利用可能な基本的な
CAPは、利用可能な基本的な追求ではない「いつでも、読み取りおよび書き込みが成功しています。」部分的な可用性の損失を許容する予測不可能な障害の時に利用可能な強調基本的な分散システムは、通常のシステムに比べて、応答時間はコア機能が利用可能であることを確実にするために拡張することができる、またはサービスがダウングレードされます。
例えば、人々の数があまりにも多くのより多くのピークはシステムの安定性を保護するために合理的な手段を介して行われ、システムのかもしれないプロンプトラインまたは流量制限を、QPSよりを購入する場合、二から一一スパイク活動の主なサービスが正常であることを保証します基本的な利用可能性を確保。
2.柔らかい状態
ソフト状態が強い整合性を行うか、全体をしないのいずれか達成され、アトミックACIDトランザクション、ACIDトランザクションに対応することができ、すべてのユーザーが同じデータを参照してください。アトミック（不可分）はデータのコピー前記複数のノードが同じである必要があり、データの整合性を強調する。
ACID一貫性モデルは、主にデータベースの実装に使用される、強い強調原子性、一貫性、分離性と耐久性です。
原子、すなわち、システムが異なるノードの拡張データ内のデータの複数のコピーが存在することを可能にする、ソフト状態は、システム内のデータが中間状態であり、状態はシステム全体の可用性に影響を与えないことを可能にすることである、「ハード状態」として理解することができます時間。
ベース指向の理論可用性の高い、スケーラブルな分散システム、伝統的な金融や他のサービスのためのACIDは、実際の場面では、データの一貫性のためのさまざまなビジネス要件は同じではありません。
3.最終合意
時間制限は、データの整合性のすべてのコピーは、データが到達していることを確認する必要があります後のデータは、常に、一定の期間内の各ノード（「矛盾の窓」として、この時間）の後に一貫性を達成しなければならない、柔らかな状態にすることはできません最後の一貫性。
システム設計では、最終的な一貫性を達成するための時間は、ネットワークレイテンシ、システム負荷、異なる記憶装置の選択は、このようなデータ複製などの様々な設計要素に依存します。
BASE CAPは、理論的には遅延の一貫性を確保するため、ネットワークの待ち時間、柔らかい状態とBASEと最終的には一貫性を解決しません。酸と塩基が反転され、それは完全に異なるモデルACID強い一貫性であるが、利用可能性が強い整合性を犠牲にして得られたデータは、時間の経過とともに失われることができ、最終的に一貫性のある状態に達しています。
一貫性モデル
それは因果一貫性と一貫性のセッションなど、より多くのモデル、に分けることができます提供していることを保証するために、最終的な一貫性モデルに応じて。
因果一貫性
因果一貫性は、一連の操作は、非因果関係は重要ではありませんであることを保証するために業務の因果関係が必要です。
Bのプロセスに通知するために、データの項目を更新する最後のプロセスは、プロセスB後のデータ項目へのアクセスは、プロセスA、Bの最新の更新値を得ることができる必要がありますし、そのデータ項目を更新するために、プロセスがされている場合そう、必ずプロセスAの最新の値をもとに更新されること。
アプリケーションシナリオの因果一貫あなたにWeiboマイクロチャンネルにコメントするとき、例を与えるか、または、たとえば、あなたが友人の円の中に写真を送って、友人ができ上のコメント、およびあなたの友人のコメントその応答、およびこの他のデータは何の因果関係は矛盾許されないことができている間に友人のサークルでの表示は、あなたの応答は、友人に従わなければならない、これは、因果関係です。
セッションの一貫性
プロセス・ブロックアクセスセッションデータの一貫性「同じアクティブなセッションの実現を確保することに同意したシステム間の会話の中でシステムを設定します私たち自身によって書かれた読み取り、あなたの最初の訪問で、アイデンティティー」、実行更新後、クライアントは常に同じセッション内のデータ項目の最新の値を読み取ることができます。
実際の開発は、それがセッションの一貫した適用と考えることができ、セッションの一貫性を配布しました。
五、CPと選択肢のAPアーキテクチャ
一貫性のビジネス要件を直接システム設計に反映され、それはCPとAPの典型的な構造です。
CPのアーキテクチャ
CPのアーキテクチャ：CPについては、可用性が一貫してパーティションフォールトトレランスの追求を放棄します。
ZooKeeperのは、CPの一貫性の使用で、ZooKeeperのは、主にシステムのアプリケーションで分散クラスタの調整と一貫性の問題点を解決するために使用される分散サービスフレームワークです。そのコアアルゴリズムはザブは、すべての一貫性を保つために設計されています。CAPモデルでは、ZooKeeperのは、ネットワーク分割に直面したとき、一貫性を維持するために、それが利用可能でないことを意味し、CPです。パーティション後、Aのために、唯一のサブ領域ノードは定足数外国サービスたより大きい
APアーキテクチャ
APアーキテクチャ：APのために、強い一貫性（ここでは一貫性が強い一貫性であると言う）あきらめるために、パーティションのフォールトトレランスと可用性の追求が、これは多くの分散システム設計の選択で、ベースもAPに応じて拡張すること。
ユーレカ、ユーレカのZooKeeperの反対側には、SpringCloudマイクロサービス・テクノロジー・スタックサービス発見コンポーネント、各ノードユーレカで通常の作業に影響を与えないノードの複数のノードがハングアップ、等しく、残りの部分はまだ登録や問い合わせを提供することができますこのサービスは、限りまだユーレカがあるので、我々は最終的な一貫性を達成するための一貫性を保証するものではありません、登録サービスが利用可能であることを保証することができますが、最新のバージョン情報に記載されていないかもしれません。
リファレンスソース
CAP定理分散、なぜ3つの特性を満たすことができませんか？
分散技術の原則と実践的な45言う：プルフック列
CAP定理-分散理論（）
CAP定理と証明
の意味CAP定理の
CAP定理