当我试图理解CAP中的“Availability”(A)和“Partition tolerance”(P)时,我发现很难理解各种文章的解释。
我有一种感觉,a和P可以同时出现(我知道事实并非如此,这就是我不能理解的原因!)
简单地解释一下,什么是A和P以及它们之间的区别?
当我试图理解CAP中的“Availability”(A)和“Partition tolerance”(P)时,我发现很难理解各种文章的解释。
我有一种感觉,a和P可以同时出现(我知道事实并非如此,这就是我不能理解的原因!)
简单地解释一下,什么是A和P以及它们之间的区别?
当前回答
一致性:
对于给定的客户端,读操作保证返回最近的写操作(如ACID)。如果在此期间有任何请求,则必须等待节点之间/节点内的数据同步完成。
可用性:
每个节点(如果没有失败)总是执行查询,并且应该总是响应请求。它是否返回最新的副本并不重要。
Partition-tolerance:
当发生网络分区时,系统将继续工作。
关于AP,可用性(始终可访问)可以与(Cassendra)或 没有(RDBMS)分区容忍
图片来源
其他回答
一致性:
对于给定的客户端,读操作保证返回最近的写操作(如ACID)。如果在此期间有任何请求,则必须等待节点之间/节点内的数据同步完成。
可用性:
每个节点(如果没有失败)总是执行查询,并且应该总是响应请求。它是否返回最新的副本并不重要。
Partition-tolerance:
当发生网络分区时,系统将继续工作。
关于AP,可用性(始终可访问)可以与(Cassendra)或 没有(RDBMS)分区容忍
图片来源
理解CAP定理的简单方法:
In case of network partition, one needs to choose between perfect availability and perfect consistency. Picking consistency means not being able to answer a client's query as the system cannot guarantee to return the most recent write. This sacrifices availability. Picking availability means being able to respond to a client's request but the system cannot guarantee consistency, i.e., the most recent value written. Available systems provide the best possible answer under the given circumstance.
这个解释来自这篇优秀的文章。希望能有所帮助。
我觉得任何答案都没有很好地解释分区容忍,所以只是更详细地解释一下CAP定理的意思是:
C:(线性性或强一致性)大致是指
如果操作B在操作A成功完成后启动,则 操作B必须看到系统处于与打开时相同的状态 完成操作A,或更新状态(但绝不是旧状态)。
A:
“系统中非故障[数据库]节点接收到的每个请求 必须导致[非错误]响应”。这对某些人来说是不够的 节点能够处理请求:任何未失败的节点都需要这样做 能够处理它。许多所谓的“高可用性”(即低可用性) 停机时间)系统实际上不符合这个定义 可用性。
P:
分区容忍(命名不当)基本上意味着您 通过可能延迟或中断的异步网络进行通信 消息。互联网和我们所有的数据中心都有这个特性,所以 在这件事上你真的没有选择的余地。
来源:Martin kleppmann的作品
举个例子: 卡桑德拉最多只能是AP系统。但是,如果您将其配置为基于Quorum进行读写,那么它就不会保持CAP可用性(根据CAP定理的定义可用),而只是P系统。
根据上图C是断开的,但A,B, D可以继续工作。现在我们可以调用系统部分工作(分区容忍)。
假设一个特定的事务只需要a、B和d,系统可以执行它而不会产生任何不一致。
但是当C必须参与一个特定的事务时,系统可以以两种方式执行。
1.由于C不可用,A可以拒绝用户请求。
So the system has Partition-Tolerance and consistency (P,C).
But no availability, because of the rejection.
2.A可以将C接收到的消息保存在A的本地内存中,并在C连接回来时传输。
So the system has Partition-Tolerance and availability (P,A).
But no consistency.because C has not updated.
Brewer's keynote, the Gilbert paper, and many other treatments, places C, A and P on an equal footing as desirable properties of an implementation and effectively say 'choose two!'. However, this is often considered to be a misleading presentation, since you cannot build - or choose! - 'partition tolerance': your system either might experience partitions or it won't. CAP is better understood as describing the tradeoffs you have to make when you are building a system that may suffer partitions. In practice, this is every distributed system: there is no 100% reliable network. So (at least in the distributed context) there is no realistic CA system. You will potentially suffer partitions, therefore you must at some point compromise C or A.
https://github.com/henryr/cap-faq#10-why-do-some-people-get-annoyed-when-i-characterise-my-system-as-ca