我不知道这是否是一个合适的问题。
众所周知，在 CAP 定理中，“A”表示“可用性”。在wikipedia上，“可用性”的解释是：
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' 甚至更高？
我建议您避免使用 Wikipedia，而是阅读Gilbert 和 Lynch证明中提供的定义。
“系统中非故障节点收到的每个请求都必须产生响应”
以及回答您问题的相关脚注
“Brewer 最初只要求几乎所有请求都能收到响应。由于允许概率可用性不会在发生任意故障时改变结果，为简单起见，我们要求 100% 可用性”
因此，如果几乎所有请求都收到响应，或者我们允许发生任意故障，则可以认为系统具有高可用性。
CAP 中的可用性意味着“所有（非故障）节点都可用于查询”。它与关于“高可用性”的维基百科链接无关。
例如，PAXOS 算法是 CP（无可用性属性），因为少数节点在分区期间“关闭”。但是如果你需要一致性，那么 PAXOS 被认为是“高可用性”。
相反，单节点 MySQL 数据库服务器是 CA（具有 CAP 可用性属性）。它可以重新启动（并且在进行 BIOS 检查、文件系统检查、数据库修复等时会关闭数小时）。当它完成启动时，它会再次开始响应查询。这是完美的可用性（根据 CAP 定理），但“高可用性”的可用性却很糟糕。
我同意 Mark Burgess的观点：CAP 定理不是定理。Brewer 猜想中的 CAP 属性根本不够明确，无法提供严格的数学证明。因此，可用性难以“理解”的原因可能是因为它在这种情况下没有明确定义。
Coda Hale的一个有趣的观点
选择可用性的系统将通过继续服务所有请求来处理网络分区，即使它们导致不一致（例如，不同网络分区中的节点都接受可能发生冲突的写入）。
选择一致性的系统将限制网络分区期间合法操作的数量（例如，不接受写入，因为它们可能导致冲突/不一致）。
不可能同时选择两者。
我想一个假设的系统也可以选择在网络分区期间崩溃，但这似乎不是一个非常实用的设计......