试图了解CAP

由Brewer陈述并由Gilbert和Lynch证明的CAP定理指定了分布式系统的性质。 它指出，这样的系统不能同时保证一致性，可用性和分区容忍度。 它也经常被说成是一个吸引人的短语：

一致性，可用性，分区容限–选择任意两个

在谈论NoSQL数据库并建议将分布式系统的特征可以描述为CA，AP或CP时，通常使用它（例如，请参见此处 ）。

一段时间以来，我一直在试图了解不同的组合及其在实践中的含义。 我在各个机场都花了一些时间来读书，这就是我的想法。

什么是C，A和P？

首先，根据我读过的一些文章，定义我对这三个保证的理解。

一致性是最简单的一种。 这大致意味着客户端获得了相同的数据视图。 说系统是一致的，我们通常是指很强的一致性，但是它也可以有不同的风格，例如随便 。

可用性是一个属性，它表示对非故障节点的每个请求都将返回（有意义的）响应。 响应可能不会包含所有数据（因此收成不会是100％，请参见[3]中的相应部分），但是对客户来说应该有用。

分区容限意味着即使节点之间发送的任何数量的消息丢失，系统也将继续运行。 例如，这可能是两个数据中心之间的网络故障，其中每个数据中心中的节点形成一个分区。 还要注意，任何数量的节点故障都会形成一个分区（无法区分网络故障和节点故障并停止响应消息的节点）。

对我而言，最难的部分是了解可用性和分区容限之间的区别。 另外，各种文章也没有通过说一个系统在例如被分区后“正在工作”来说明它们的意思–是意味着每个请求都得到包含有用数据的响应，还是响应“对不起，我不能给出您现在的数据“还可以接受吗？

P + C？

让我们假设一个系统是分区容错的，并且它有多个节点。 如果形成分区，将系统分为两部分，则系统应继续工作。 因此，两个分区都允许客户端写入。 但是，如何保证一致性呢？ 如果一个客户端写入分区1，另一个客户端写入分区2？ 因此： P =>〜C 。

A +〜P？

假设现在有一个系统可用，并且我们有多个节点。 当系统可用时，即使某些节点死亡，它也应响应请求。 如上所述，一些即将死亡的节点等效于一个分区。 因此，如果系统仍在工作，则我们具有分区容限。 因此： A => P。

A + C？

总结以上两个含义（A => P和P =>〜C），我们得到： A =>〜C ，因此可用系统无法保持一致（如果它有多个节点）。 但是实际上，实际上有AC系统，例如单节点RDBMS。 甚至主从/主-主复制RDBMS，只要有一个中央路由器就知道哪些节点处于活动状态并适当地引导客户端即可。 这样的路由器就是单故障点（SPoF）。

放松？

我怀疑实际上，当NoSQL / NewSQL系统以CAP属性为特征时，它们会采用某种宽松的C / A / P形式。 不幸的是，所有绕过的定义似乎都含糊不清，比恰当，准确的陈述更容易动摇。 我认为，如果能够更轻松地描述它们，探索不断发展的新数据存储生态系统将容易得多。 也许CAP词汇还不够？

如果我在某个地方错了，请纠正我，我可能是！ :)

别忘了分享！

参考：在Adam Warski博客的Blog中， 试图从我们的JCG合作伙伴 Adam Warski 了解CAP 。

翻译自: https://www.javacodegeeks.com/2012/09/trying-to-understand-cap.html