Sql CAP定理错了吗？

CAP定理定义摘自维基百科：

分布式计算机系统不可能同时提供以下三种保证：

• 一致性（每次读取都会收到最近的写入或错误）
• 可用性（每个请求都会收到响应，但不保证其中包含最新版本的信息）
• 分区容差（即使由于网络故障而进行任意分区，系统仍能继续运行）

我的想法是：

---

对于任何具有CA的系统，它们都可以在没有分区的情况下正常运行。当存在分区时，系统可以退回到CP或AP，后者可以继续运行。由于系统可以继续运行，因此它也满足P。因此，任何CA系统也是CAP系统。因此，声称所有CAP不可能在一个系统中共存的说法是错误的。

C这意味着系统在面对分区时提供了这些保证。因此，在分区期间放弃这些属性会使该属性无法保存

CA权衡仅在分区期间相关（因为没有分区，我们可以放弃p而获得CA）。然后，你需要做出决定

实际上相关的选择是CP与AP，因为分区总是可能发生的

首先，关于你的假设

实际上，

CA

和

CP

是相同的，因为如果

CA

系统获得一个网络分区，它将失去

可用性

。因此，这种情况迟早会发生，因为随着节点数量的增加，任何节点发生故障的概率都会呈指数级增加

您需要知道，当您忽略

CAP定理

中选择

CA

并忽略或离开

p

的选项时，这将在分布式系统的整个生命周期内保持不变。因此，我们无法实际实现

CA

，而我们可以有效地实现这一点，就像Google Cloud Paner数据库一样，该数据库声明它是

99.999%

可用的，因此它并不保证会有

100%

可用性，但它保证它将非常小，以至于可能会被业务忽略

同时，Postgresql数据库可以通过复制有效地实现

CA

上述所有数据库都试图通过保持一定程度的一致性和可用性来维护CA

第二，CAP定理错了吗

对

CAP定理有一些批评意见

：

由代码> CAP定理所考虑的唯一故障是一个网络分区，这种故障绝对发生，但它不是唯一可以出错的事情，因为节点可能崩溃，您可以在软件中遇到错误，所以我们需要考虑更大范围的权衡。

CAP定理

没有提到延迟，人们往往关心的不仅仅是可用性。事实上，

CAP定理

可用系统的响应速度可以任意变慢，并且仍然可以被称为可用系统。如果加载页面需要2分钟，用户就不会调用我们的系统

Available

当存在

分区时，倾向于放弃
一致性
以获得
可用性
，当存在
无
分区时，也倾向于放弃
一致性
以获得
延迟

CAP定理

中的

C

和

A

是

不对称的

，因为牺牲

一致性的系统（AP系统）往往总是这样做，而不仅仅是在存在网络分区时。同样，对于牺牲可用性（CP系统）的系统也是如此，它往往总是这样做，而不仅仅是在存在网络分区时。这意味着它不是始终一致的，也不是始终可用的。在前两种情况下，它们是不可用的无用系统，因为
CAP定理
没有给出系统正常运行时会发生什么的视图

---

不确定这个问题出了什么问题？完全正确，尽管是错误的理论。谢谢你的回答。你的意思是CAP是一种状态，因为你说过“没有分区，我们可以放弃P并获得CA”？CAP是系统的一个属性，一个属性必须始终保持它。更好的说法是“如果我们假设没有分区，我们应该构建一个CA系统，因为我们不需要属性P。”所以CAP定理实际上是从CA中选择1，而不是从CAP中选择2。若CAP是一个必须始终为真的属性，那个么在存在分区的情况下，CA系统将无法保持其保证。谢谢你消除了我的困惑。@netok这仍然是三分之二。阅读维基百科文章中引用的内容。“允许至少一个节点更新状态将导致节点变得不一致，从而放弃C。同样，如果选择保持一致性，则分区的一侧必须充当不可用的角色，从而放弃A。只有当节点通信时，才能同时保持一致性和可用性，从而放弃P。”。一般认为，对于广域系统，设计师不能放弃P…。”或者，另一句话是“假设没有分区，我们会得到一个更强的结果，即CAP的所有3个。”