专家一直试图解释CAP定理并不代表人们的想法，也不是对数据库进行分类的正确工具。 但是最后，真正的意义并不重要。 这与大多数人的想法有关。 因此，我试图总结人们在现实中说CAP时的真正含义。 这是错误的，但是更有用。
与传统的关系数据库一样， CP通常意味着一致性。 严格的形式意味着读/写被序列化，这仍然小于真正的CAP consistency 。 尽管在许多情况下，读取自己拥有的写操作的松散形式就足够了，这就是许多NoSQL数据库在声称为CP时的含义。 一个示例是MongoDB，即使默认配置不能保证在某些故障情况下也是如此。 您必须以更高的性能成本选择更强大的保证。
尽管许多人认为AP是指正常的高可用性。 如果是关于正常的高可用性， CP数据库也可以提供，那么大多数数据库都可以提供全部CAP 。 取而代之的是，它更多是关于低延迟的情况，在这种情况下，暂时的不一致是比必须等待更好的选择，这是高可用性的一种极端形式。 当数据库声称是AP ，通常意味着只要客户端仍可以访问某些副本，该数据库将始终按时提供读/写服务。 它涵盖了所有类型的故障，而不仅仅是网络分区。 卡桑德拉就是一个例子。
根据上下文， P可能表示两种不同的含义：
- 一个人只是在谈论横向扩展的能力，这种能力在某种程度上也与可用性重叠。
- 另一个更多的是关于在广域网中进行分区，而不是在同一局域网中的群集节点。 一个典型的示例是跨不同数据中心的副本（或跨服务器和客户端计算机的副本）。 在这种情况下，存在高延迟，因此在实践中状态同步几乎总是异步的，这意味着即使
CP数据库也无法保证强一致性。
实际上，不能牺牲P。 如果没有P ，则几乎无法提供高可用性，因为单个节点可能会崩溃，因此没有CA数据库。 从这个意义上说，传统的单节点关系数据库只是C 而且，当使用故障转移设置时，即使故障转移确实解决了高可用性问题，也可以将其视为CP类别。 ♂️
但是，无论声称拥有什么数据库，都有一种趋势，即数据库会停止对它们说CP或AP 。 相反，取决于它们的配置方式，它们可以是CP或AP 。
