これがここで適切な質問であるかどうかはわかりません。
ご存知のように、CAP定理では「A」は「可用性」を意味します。ウィキペディアでは、「可用性」の説明は次のとおりです。
Availability: a guarantee that every request receives a response about whether it was successful or failed
ただし、エンジニアリングの観点からは、絶対的な可用性はありません。システムの可用性は5'9'（99.999％）、さらには8'9'としか言えませんが、システムの可用性が100％であるとは言えず、100％利用可能なシステムは実際には存在しません。 、システムに何百万もの重複ノードがある場合でも、そうですか？
CAP定理は、3つの要件を同時に満たすシステムはないことを証明しています。私の質問は、システムが「A」と「P」の両方を満たすと主張する場合、この「A」の正確な意味は何ですか？6'9'またはそれ以上？
ウィキペディアを避け、代わりにギルバートとリンチによる証明で提供されている定義を読むことをお勧めします。
「システム内の障害のないノードが受信したすべての要求は、応答をもたらす必要があります」
そしてあなたの質問に答える関連する脚注
「Brewerは元々、応答を受信するためにほとんどすべてのリクエストのみを必要としました。確率的な可用性を許可しても、任意の障害が発生しても結果は変わらないため、簡単にするために100％の可用性が必要です。」
したがって、ほとんどすべての要求が応答を受信するか、任意の障害の発生を許可する場合、システムは高可用性を備えていると見なすことができます。
CAPの可用性は、「すべての（障害のない）ノードがクエリに使用できる」ことを意味します。「高可用性」に関するウィキペディアのリンクとは何の関係もありません。
たとえば、PAXOSアルゴリズムはCP（可用性プロパティなし）です。これは、少数ノードがパーティション中に「シャットダウン」するためです。ただし、一貫性が必要な場合、PAXOSは「高可用性」と見なされます。
逆に、単一ノードのMySQLデータベースサーバーはCAです（CAP可用性プロパティがあります）。再起動できます（BIOSチェック、ファイルシステムチェック、DB修復などを実行している間は数時間ダウンします）。起動が完了すると、クエリへの応答を再開します。これは完全な可用性（CAP定理による）ですが、「高可用性」の恐ろしい可用性です。
私はマークバージェスに同意します：CAP定理は定理ではありません。ブリューワーによる推測のCAPプロパティは、厳密な数学的証明を提供するのに十分に明確に定義されていません。したがって、可用性を「理解」するのが難しい理由は、このコンテキストでは単に明確に定義されていないためである可能性があります。
CodaHaleによる興味深い視点
可用性を選択したシステムは、不整合が発生した場合でもすべての要求を処理し続けることでネットワークパーティションを処理します（たとえば、異なるネットワークパーティション内のノードは両方とも競合する可能性のある書き込みを受け入れます）。
整合性を選択するシステムは、ネットワークパーティション中の合法的な操作の量を制限します（たとえば、書き込みは競合/不整合につながる可能性があるため、受け入れられません）。
両方を選択することはできません。
架空のシステムでもネットワークパーティション中にクラッシュすることを選択できると思いますが、これはあまり実用的な設計ではないようです...