CAP定理 – 可用性和分区容差

当我尝试理解CAP中的“可用性”(A)和“分区容忍”(P)时,我发现很难理解各种文章的解释。

我感觉A和P可以一起走(我知道情况并非如此,这就是为什么我不明白!)。

简单地说,A和P是什么,它们之间的区别是什么?

一致性意味着群集中的数据是相同的,所以您可以读取或写入任何节点并从中读取数据并获取相同的数据。

可用性意味着即使群集中的节点出现故障,也能够访问群集。

分区容差意味着即使在两个节点之间存在“分区”(通信中断)(两个节点都处于启动状态,但无法通信),集群也会继续运行。

为了获得可用性和分区容错,你必须放弃一致性。 考虑在主 – 主设置中是否有两个节点X和Y. 现在,X和Y的networking通信之间有一个中断,所以它们不能同步更新。 在这一点上,你可以:

A)允许节点不同步(放弃一致性),或者

B)考虑群集“下降”(放弃可用性)

所有可用的组合是:

  • CA – 所有节点之间的数据是一致的 – 只要所有节点都在线,并且您可以从任何节点读取/写入,并确保数据是相同的,但是如果您在节点之间开发分区,则数据将是不同步(并且一旦分区被解决,将不会重新同步)。
  • CP – 数据在所有节点之间保持一致,并在节点closures时保持分区容差(防止数据asynchronous)变得不可用。
  • AP – 节点保持在线状态,即使它们无法相互通信,并且在分区parsing后将重新同步数据,但不能保证所有节点将具有相同的数据(在分区期间或之后)

您应该注意到, CA系统实际上并不存在 (即使有些系统声称如此)。

考虑与C和A平等的P是一个错误,而C,A,P中的“2/3”概念是误导性的。 我将解释CAP定理的简洁方法是:“在分布式数据存储中,在networking分区时,您必须select”一致性“或”可用性“,而不能同时select”。 较新的NoSQL系统正试图把重点放在可用性上,而传统的ACID数据库则更关注一致性。

你真的不能selectCA,networking分区不是任何人想要的,这只是分布式系统的不良现实,networking可能会失败。 问题是什么权衡你select你的应用程序,当发生这种情况。 来自首先提出这个词的那个人的这篇文章似乎很清楚地解释了这一点。

以下是我如何讨论CAP,尤其是P。

如果您对单一的单一服务器数据库(可能有复制,但所有数据在一个“故障块” – 服务器不被视为部分失败),那么CA是唯一可能的。

如果您的问题需要扩展,分布式和多服务器—networking分区可能会发生。 你已经要求P了。我接近的几个问题都适用于单服务器总是范式(或者,正如Stonebraker所说的,“分布式是表赌注”)。 如果您可以find一个CA问题,像传统的非扩展RDBMS这样的解决scheme会带来很多好处。

对我来说,很less见:所以我们继续讨论AP和CP。

有分区时,您只能在AP和CP操作之间进行select。 如果networking和硬件运行正常,你得到你的蛋糕,也吃了。

我们来讨论AP / CP的区别。

AP – 当有networking分区时,让独立部分自由运行。

CP – 当存在networking分区时,closures节点或不允许读取和写入,以确定性故障。

我喜欢可以兼得的架构,因为有些问题是AP,有些是CP,有些数据库可以兼得。 在CP和AP解决scheme中,也有微妙之处。

例如,在AP数据集中,您可能会同时读取不一致的数据,并产生写入冲突 – 这是两种不同的AP模式。 您的系统能否configuration为具有高读取可用性的AP,但不允许写入冲突? 或者,您的AP系统是否可以接受写入冲突?具有强大而灵活的解决scheme系统? 你最终会需要两个,还是可以select一个只有一个的系统?

在CP系统中,如果使用小分区(单个服务器),可获得多less不可用性? 更大的复制会增加CP系统中的不可用性,系统如何处理这些权衡?

这些都是要问CP与AP的问题。

现在这个领域的一个伟大的阅读是布鲁尔“12年后”的职位。 我相信这会明确地推动CAP的辩论,并高度推荐它。

http://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed

考虑与C和A平等的P是一个错误,而C,A,P中的“2/3”概念是误导性的。 我将解释CAP定理的简洁方法是:“在分布式数据存储中,在networking分区时,您必须select”一致性“或”可用性“,而不能同时select”。 较新的NoSQL系统正试图把重点放在可用性上,而传统的ACID数据库则更关注一致性。

一致性 – 当我们发送读取请求时,如果返回结果,它应该返回客户端请求给出的最近的写入。 可用性 – 您的读/写请求应始终成功。 分区容错 – 当出现networking分区(某些机器相互通讯问题)时,系统仍然可以正常工作。

在分布式中,有可能发生networking分区,我们无法避免CAP的“P”。 所以我们select“一致性”和“可用性”。

http://bigdatadose.com/understanding-cap-theorem/

CAP定理

一致性:

读保证返回给定客户端的最近写入(如ACID) 。 如果在此期间有任何请求发生,则必须等待数据同步完成 /跨节点。


可用性:

每个节点(如果没有失败)总是执行查询,并且应该总是响应请求。 它是否返回最新的副本并不重要。


分区容忍:

networking分区发生时,系统将继续运行。


关于AP ,可用性(始终可访问)可以存在( Cassendra )或不存在( RDBMS )分区容差

图片来源

Interesting Posts