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

理解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.

这个解释来自这篇优秀的文章。希望能有所帮助。

根据上图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.

以下是我讨论CAP的方式，特别是关于P。

CA只有在单机数据库(可能有复制，但所有数据都在一个“故障块”上-服务器不被认为是部分故障)的情况下才可能使用。

如果您的问题需要向外扩展、分布式和多服务器，则可能发生网络分区。您已经需要p了，我所处理的问题中很少有适用于总是单服务器的范例(或者，如Stonebraker所说，“分布式是桌面赌注”)。如果您能找到CA问题，那么像传统的非向外扩展RDBMS这样的解决方案将提供很多好处。

对我来说，罕见:所以我们继续讨论AP和CP。

当您有分区时，只能在AP操作和CP操作之间进行选择。如果网络和硬件运行正常，你就能得到你的蛋糕并吃掉它。

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

AP -当有网络分区时，让独立的部分自由运行。

CP——当存在网络分区时，关闭节点或禁止读写，这样就会出现确定性故障。

我喜欢能两者兼顾的架构，因为有些问题是AP问题，有些是CP问题，而有些数据库可以两者兼顾。在CP和AP解决方案中，也有一些微妙之处。

例如，在AP数据集中，您可能同时存在不一致的读取和生成写入冲突-这是两种不同的AP模式。您的系统是否可以配置为具有高读可用性但不允许写冲突的AP ?或者您的AP系统可以接受写入冲突，具有强大而灵活的解决系统?你最终需要两者吗，或者你可以选择一个只做其中一个的系统?

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

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

现在在这个领域有一个很好的阅读是Brewer的“12年后”的帖子。我相信这将清晰地推进CAP辩论，并强烈推荐它。

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

将P与C和A等同看待是一个错误，而C、A、P之间的“三选二”概念是具有误导性的。我解释CAP定理的简洁方式是，“在分布式数据存储中，在网络分区时，你必须在一致性或可用性中选择一个，并且不能两者兼得”。新的NoSQL系统正试图关注可用性，而传统的ACID数据库则更关注一致性。

你真的不能选择CA，网络分区不是任何人都想要的，它只是分布式系统的一个不受欢迎的现实，网络可能会失败。问题是，当这种情况发生时，你如何权衡你的应用程序。第一个提出这个术语的人的这篇文章似乎很清楚地解释了这一点。

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