实际上,CAP并不意味着CAP定理的含义

专家一直试图解释CAP定理并不代表人们的想法,也不是对数据库进行分类的正确工具。 但是最后,真正的意义并不重要。 这与大多数人的想法有关。 因此,我试图总结人们在现实中说CAP时的真正含义。 这是错误的,但是更有用。

与传统的关系数据库一样, CP通常意味着一致性。 严格的形式意味着读/写被序列化,这仍然小于真正的CAP consistency 。 尽管在许多情况下,读取自己拥有的写操作的松散形式就足够了,这就是许多NoSQL数据库在声称为CP时的含义。 一个示例是MongoDB,即使默认配置不能保证在某些故障情况下也是如此。 您必须以更高的性能成本选择更强大的保证。

尽管许多人认为AP是指正常的高可用性。 如果是关于正常的高可用性, CP数据库也可以提供,那么大多数数据库都可以提供全部CAP 。 取而代之的是,它更多是关于低延迟的情况,在这种情况下,暂时的不一致是比必须等待更好的选择,这是高可用性的一种极端形式。 当数据库声称是AP ,通常意味着只要客户端仍可以访问某些副本,该数据库将始终按时提供读/写服务。 它涵盖了所有类型的故障,而不仅仅是网络分区。 卡桑德拉就是一个例子。

根据上下文, P可能表示两种不同的含义:

  • 一个人只是在谈论横向扩展的能力,这种能力在某种程度上也与可用性重叠。
  • 另一个更多的是关于在广域网中进行分区,而不是在同一局域网中的群集节点。 一个典型的示例是跨不同数据中心的副本(或跨服务器和客户端计算机的副本)。 在这种情况下,存在高延迟,因此在实践中状态同步几乎总是异步的,这意味着即使CP数据库也无法保证强一致性。

实际上,不能牺牲P。 如果没有P ,则几乎无法提供高可用性,因为单个节点可能会崩溃,因此没有CA数据库。 从这个意义上说,传统的单节点关系数据库只是C 而且,当使用故障转移设置时,即使故障转移确实解决了高可用性问题,也可以将其视为CP类别。 ♂️

但是,无论声称拥有什么数据库,都有一种趋势,即数据库会停止对它们说CPAP 。 相反,取决于它们的配置方式,它们可以是CPAP