CAPは、一貫性、可用性、およびパーティショントレランスの最初の文字です。IBMCloud Docs / Wikipedia / Baidu Baikeなど、資料によって、これら3つの単語の解釈が少し異なります。CAP理論の定義も変更されました。初版の説明ではそうだった对于一个分布式计算系统而言，不可能同时满足一致性、可用性和分区容错三个设计规约、そして第二版の説明は在一个分布式系统（指互相连接并共享数据的节点的集合）中，当涉及读写操作时，只能保证一致性、可用性和分区容错三者中的两个，另一个必须被牺牲
ただし、CAP理論で説明されている分散システムは相互接続とデータ共有を強調しているという説明から理解することは難しくありません。たとえば、Memcacheクラスタは相互接続とデータ共有の特性を持たないため、MySQLクラスタはCAP理論の説明の対象ではありません。 CAP理論は議論の対象であり、CAP理論は、読み取りおよび書き込み操作では、分散システムの完全な機能ではなく、読み取りおよび書き込み操作に焦点を当てていることにも言及しています
一貫性
説明の最初のバージョンは、すべてのノードが同時に同じデータを参照できることです。説明の2番目のバージョンは、指定されたクライアントの場合、読み取り操作が最新の書き込み操作結果を返すことが保証されていることです。違いは非常に明白です。
- 第1版はノードの観点から問題を検討し、第2版はクライアントの観点から問題を検討します
- 最初のバージョンはノードが所有するデータを考慮し、2番目のバージョンはクライアントの読み取りおよび書き込みパースペクティブを考慮します
- 第1版では、ノードが同じデータを同時に持つことを強調していますが、第2版ではそのようなステートメントを強調していません。実際、システムトランザクションの場合、トランザクションの実行中、システムは実際には一貫性のない状態にあり、異なるノードのデータは完全ではありません。一貫性があるため、第2版では、トランザクションの実行中にクライアントがコミットされていないデータを読み取ることができないため、クライアントの読み取り操作で最新の書き込み結果を取得できることが強調されています。クライアントは、トランザクションが送信された後にのみコミットされていないデータを読み取ることができます。トランザクションが失敗した場合、トランザクションによって書き込まれたデータはロールバックされ、クライアントはトランザクションの途中で書き込まれたデータを読み取れません
可用性
第1版では、すべての要求が成功または失敗で応答できることを強調し、第2版では、障害のないノードが妥当な時間内に妥当な応答（エラーおよびタイムアウト応答ではない）を返すことを強調しています。違いも明らかです。
- 最初のエディションではすべてのリクエストが強調され、2番目のエディションでは障害のないノードが強調されます。これは、障害が発生したノードが応答を取得できない可能性があるため、明らかにより厳密です。可用性の要件を満たすことができるのは、障害が発生していないノードの存在のみです。
- 第1版は、応答が成功と失敗に分かれることを強調し、第2版は、合理的な応答と合理的な時間を強調し、エラーやタイムアウトがないことを強調しています
パーティションの許容度パーティションの許容度
第1版では、メッセージの損失やパーティションエラーが発生してもシステムは動作し続けることができることを強調しています。第2版では、ネットワークパーティションが発生した後もシステムが「機能を実行」できることを強調しています。違いは非常に明白です。
- 第1版はシステムの運用を強調していますが、第2版はシステムがシステム運用を前提として業務を遂行できることを強調しています。
- 第1版はメッセージの損失または部分的な障害に重点を置いており、第2版はネットワークパーティションを直接使用しています。第1版で述べたメッセージの損失（パケット損失）はネットワーク障害の一種にすぎません。第2版は現象について直接語っています。理由に関係なく、パーティション分割現象は、ネットワークパーティションが発生している限り、パケット損失、ネットワークの中断、またはネットワークの輻輳である可能性があります。
CAPの選択
CAPが2つしか選択できず、1つをあきらめて分散環境でそれを考慮する必要がある場合、ネットワーク自体は100％信頼できないため、Pは必要な要素です。理論的には、分散システム用のCAアーキテクチャを選択することは不可能です。 CPおよびAPアーキテクチャを選択
CP整合性/パーティション許容度
一貫性を確保するために、ネットワークパーティションが発生すると、ノードN1のデータはYに更新されますが、N1とN2の間のネットワークの中断により、データYはN2に同期できず、ノードN2のデータはXのままです。このとき、お客様はクライアントがN2にアクセスすると、クライアントシステムが失敗したことを示すエラーを返す必要があります。この処理方法は可用性の原則に違反しています
APの可用性/パーティションの許容範囲
可用性を確保するために、パーティション現象が発生すると、ノードN1のデータはYに更新されましたが、N1とN2の間のレプリケーションが中断されたため、データYはN2に同期できず、N2のデータはXのままです。このとき、クライアントアクセスN2では、N2が所有する現在のデータXをクライアントに返しますが、実際には現在の最新データはすでにYであり、整合性の一貫性を満たすことができません。
CAPの詳細
理論の利点は、それが明確かつ簡潔で理解しやすいことですが、欠点は、非常に抽象的であり、多くの詳細が省略されていることです。その結果、理論を実践に適用するときのさまざまな複雑な状況により、誤解や逸脱が発生する可能性があります。CAP理論も例外ではありません。CAP理論を実際に適用する必要がある場合、これらの重要な詳細を認識していないと、計画の実装が困難になる可能性があります。
CAPの注意の細分性はデータであり、システム全体ではありません
CAP理論の定義と説明では、システムやノードなどのシステムレベルの概念が使用されています。これは、アーキテクチャを設計するときにシステム全体でCPを選択するか、 AP。ただし、実際の設計プロセスでは、各システムは1種類のデータしか処理できませんが、複数の種類のデータが含まれています。一部のデータはCPを選択する必要があり、一部のデータはAPを選択する必要があります。設計すると、全体からシステムの観点からCPまたはAPを選択すると、何をしても、一方が他方を失うことがわかります。
- 最も単純なユーザー管理システムを例にとります。ユーザー管理システムには、ユーザーアカウントデータ（ユーザーID、パスワード）、ユーザー情報データ（ニックネーム、興味、趣味、性別、自己紹介など）が含まれています。通常、ユーザーアカウントデータはCPを選択すると、ユーザー情報データはAPを選択します。システム全体がCPとして定義されている場合、ユーザー情報データのアプリケーションシナリオを満たしていません。システム全体がAPとして定義されている場合、ユーザーアカウントデータのアプリケーションシナリオを満たしていません。
- したがって、CAP理論を実践する場合、システム全体のすべてのデータを同じ戦略に直接制限するのではなく、さまざまなアプリケーションシナリオと要件に従ってシステム内のデータを分類し、データの種類ごとに異なる戦略（CPまたはAP）を選択する必要があります。
CAPはネットワーク遅延を無視します
これは非常に暗黙的な仮定であり、Brewerは一貫性を定義するときに遅延を考慮していませんでした。つまり、トランザクションがコミットされると、データはすべてのノードに即座に複製されます。しかし実際には、ノードAからノードBへのデータのコピーには常に一定の時間がかかります。同じコンピュータールームの場合、数ミリ秒かかる場合があります。異なる場所にまたがるコンピュータールームの場合、数十ミリ秒かかる場合があります。これは、CAP理論のCが実際に完全に実装できないことを意味します。データ複製のプロセスで、ノードAとノードBのデータに一貫性がない
これらのミリ秒または数十ミリ秒の不整合を過小評価しないでください。技術的には、分散シナリオで完全な整合性を達成することは不可能です。ビジネスには一貫性が必要です。したがって、たとえば、単一ユーザーのバランスまたは単一製品の在庫には、理論的にはCPの選択が必要ですが、実際にはCPはそれを行うことができません。CAのみを選択できます。つまり、単一のポイントにしか書き込むことができません。他のノードはバックアップを行い、分散状況ではマルチポイント書き込みを実行できませんこれは、このタイプのシステムが分散アーキテクチャを適用できないことを意味するのではなく、「単一ユーザーの残高と単一商品の在庫」を配布できないが、システム全体が分散アーキテクチャを適用できることを意味することに注意してください。
たとえば、ユーザーを分割する一般的な分散アーキテクチャを次の図に示し
ます。ユーザーIDが0〜100のデータをNode1に格納し、ユーザーIDが101〜200のデータをNode2に格納すると、クライアントはユーザーIDに基づいて決定します訪問するノード、単一のユーザーの場合、読み取りおよび書き込み操作は特定のノードでのみ実行できます。すべてのユーザーの場合、一部のユーザーはNode1の読み取りおよび書き込み操作、一部のユーザーはNode2の読み取りおよび書き込み操作
この設計の明らかな問題は、ノードに障害が発生すると、このノードのユーザーは読み取りおよび書き込み操作を実行できないことですが、全体として、この設計により、ノードに障害が発生したときに影響を受けるユーザーの数を減らすことができます。そして、スコープは、結局のところ、すべてのユーザーに影響を与えるよりも、20％のユーザーにのみ影響を与える方が良いです。これは、すべてのユーザーではなく、掘削機が光ケーブルを切断した後、Alipayの一部のユーザーのみがビジネス異常を起こす理由でもあります。
通常の動作条件下では、CPとAPを選択することはできず、CAは同時に満たすことができます
CAP理論では、分散システムはCPまたはAPしか選択できないと説明していますが、実際の前提は、システムが「パーティション化」されていることです。システムにパーティション現象がない場合、つまりPが存在しない場合（ノード間のネットワーク接続は正常）、CまたはAをあきらめる必要はありません。CとAの両方を保証する必要があります。これには、アーキテクチャを設計するときに両方の考慮が必要です。パーティションが発生したときにCPまたはAPを選択し、パーティションが発生しないときにCAを確保する方法も検討する
また、例としてユーザー管理システムを取り上げます。CAが実装されている場合でも、異なるデータ実装方法は異なる場合があります。ユーザーアカウントデータは、「メッセージキュー」の方法で実装してCAを実現できます。メッセージキューはリアルタイムのパフォーマンスをより適切に制御できるためです。実装するのはより複雑であり、ユーザー情報データは「データベース同期」によって実装できます。これは、データベースメソッドでは、一部のシナリオでは遅延が大きくなる可能性があるためですが、使用は簡単です。
あきらめることは何もしないことを意味するのではなく、パーティションの回復の準備をする必要があります
CAP理論では、3つのうち2つしか取得できず、もう1つは「犠牲にする」必要があると言われています。実際、CAP理論の「犠牲」は、パーティション分割プロセス中にCまたはAを保証できないことを意味するだけで、すべてを意味するわけではありません。システムの全動作サイクル中のほとんどの時間は正常であり、パーティション現象は長くはかからないため、実行しないでください
たとえば、可用性が99.99％のシステム（一般的にはフォーナイン）は、1年の運用後50分間しか利用できず、99.999％の可用性（一般的にはファイブナイン）のシステムは、運用後1年で5分間しか利用できません。 。パーティション中にCまたはAを放棄することは、CおよびAを永久に放棄することを意味するわけではありません。パーティションの障害が解決した後、システムがCAの状態に再び到達できるように、パーティション中にいくつかの操作を実行できます。
最も一般的なのは、パーティション中にいくつかのログを記録することです。パーティションの障害が解決されると、システムはログに基づいてデータを復元し、CAステータスに再度到達します。また、例としてユーザー管理システムを取り上げます。ユーザーアカウントデータの場合、CPが選択されていると仮定すると、パーティション発生後、ノード1は新しいユーザーの登録を続行できますが、ノード2は新しいユーザーを登録できません（ノードAが登録要求を受信した後にエラーを返すため、ここではAに会わない理由です）、この時点でノード1は新規に登録できますが、同期されませんノード2のユーザーがログに記録されます。パーティションが復元されると、ノード1がログのレコードを読み取り、ノード2に同期します。同期が完了すると、ノード1とノード2は同時にCAを満たす状態に達します
ユーザー情報データの場合、APを選択するとします。パーティションが発生した後、ノード1とノード2の両方がユーザー情報を変更できますが、変更は両側で異なる場合があります。たとえば、ノード1とノード2は両方とも非同期の趣味データを記録します、パーティションが復元されると、システムは特定のルールに従ってデータをマージします。または、データの競合を完全に報告し、使用するものを手動で選択できます
酸ベース
酸
ACIDは、トランザクションの正確性を保証するためにデータベース管理システムによって提案された理論です。ACIDには4つの制約があります。基本的な説明は次のとおりです。
- 原子性（原子性）：トランザクションのすべての操作は完了しているか、まったく完了しておらず、中間リンクで終了しません。トランザクションの実行中にエラーが発生した場合、トランザクションが実行されたことがないかのように、トランザクションが開始される前の状態にロールバックされます。
- 一貫性：トランザクションの開始前とトランザクションの終了後、データベースの整合性は破壊されていません
- 分離C：複数の同時トランザクションが同時にデータの読み取り、書き込み、変更を行えるようにするデータベースの機能。分離により、複数のトランザクションが同時に実行された場合のクロス実行によるデータの不整合を防ぐことができます。トランザクションの分離は、コミットされていない読み取り（コミットされていない読み取り）、コミットされた読み取り（コミットされた読み取り）、繰り返し可能な読み取り（繰り返し可能な読み取り）、シリアライズ可能（シリアル化可能）など、さまざまなレベルに分かれています。
- 耐久性：トランザクションの完了後、データの変更は永続的であり、システムに障害が発生しても失われません。
ACIDのA（アトミシティ）とCAPのA（アベイラビリティ）の意味が完全に異なることは容易に理解できます。ACIDのCとCAPのCの名前は一貫していますが、それらの意味はまったく異なります。 Cはデータベースのデータ整合性を指し、CAPのCは分散ノードのデータの一貫性を指し、ACIDがデータベーストランザクションであるアプリケーションシナリオと組み合わせて、CAPは分散システムデータの読み取りと書き込みの違いに焦点を当てています。実際、CAPとACIDの比較は似ています
ベース
BASEは、Basicly Available、Soft State、およびEventually Consistencyの略です。コアとなる考え方は、強い整合性を実現できない場合でも（CAPの整合性は強い整合性です） 、ただし、アプリケーションは、結果整合性（Eventual Consistency）を達成するために適切な方法を使用できます
。BASEは、基本的に使用可能（Basically Available）、ソフト状態（Soft State）、結果整合性（Eventual Consistency）を指します
基本的に利用可能
分散システムに障害が発生すると、コアの可用性を確保するために、可用性の一部が失われる可能性があります。ここでのキーワードは「パーツ」と「コア」です。失われる可能性のあるビジネスとして具体的に選択されるものと、保証する必要のあるビジネスは、1つのアイテムです。やりがいのある仕事
ソフトな状態
システムに中間状態を許可します。中間状態はシステムの全体的な可用性に影響しません。ここでの中間状態とは、CAP理論におけるデータの不整合です。
最終的な整合性
一定の時間が経過すると、システム内のすべてのデータコピーが最終的に一貫した状態に到達できます。ここでのキーワードは、「特定の時間」と「最終」です。「特定の時間」はデータの特性と強く関連しており、さまざまなデータを許容できます。不整合時間は異なります。「最終」は、どれだけ時間がかかっても、最終的には整合状態に達することを意味します
BASE理論は本質的にCAPの拡張および補足であり、より具体的には、CAPのAPスキームの補足です。CAP理論を分析する際に、BASEに関連する2つのポイントについて説明しました。
- CAP理論は遅延を無視し、実際のアプリケーションでの遅延は避けられません。これは、たとえ数ミリ秒の間隔内で数ミリ秒のデータ複製遅延であっても、完全なCPシーンがないことを意味します。システムはCP要件を満たしていないため、CAPのCPスキームは実際には最終的な整合性を実現しますが、「一定の時間」とは数ミリ秒を指します。
- APソリューションでの一貫性の犠牲は、一貫性を永久に放棄するのではなく、分割期間のみを指します。これは、実際にはBASE理論の延長です。一貫性は、分割中に犠牲になりますが、パーティション障害の回復後、システムは最終的な一貫性に達するはずです。
上記の分析に基づくと、ACIDはデータベーストランザクションの整合性の理論、CAPは分散システム設計の理論、BASEはCAP理論におけるAPスキームの拡張です。