CAP原则介绍

一、背景：

• 1985 年，后来证明了 CAP 理论的 Lynch 教授此时给当时的 IT 界来了一记惊雷：她通过不可辩驳的证明告诉业界的工程师们，如果在一个不稳定（消息要么乱序要么丢了）的网络环境里（分布式异步模型），想始终保持数据一致是不可能的。这是个什么概念呢？就是她打破了那些既想提供超高质量服务，又想提供超高性能服务的技术人员的幻想。这本质是在告诉大家，在分布式系统里，需要妥协。
• 2000 年，Eric Brewer 教授在 PODC 会议上提出了 CAP 理论，但是由于没有被证明过，所以，当时只能被称为 CAP 猜想。这个猜想引起了巨大的反响，因为 CAP 很符合人们对设计纲领的预期。
• 2002 年，经过 Seth Gilbert 和 Nancy Lynch 从理论上证明了 CAP 猜想后，CAP 理论正式成为了分布式系统理论的基石之一。

二、CAP 到底是什么？

CAP 理论是分布式系统的基础原则，所以在讨论CAP的前提是分布式系统。

强一致性（Consistency）

• 每次读取要么获得最近写入的数据，要么获得一个错误。
  要实现一致性，那么需要保证：当在分布式系统更新一个节点的数据时候，分布式系统会立马把这个数据同步到所有的节点上。要么所有节点都更新数据，要么都不更新。始终保持所有节点数据一致。并且在这个数据同步期间，分布式系统不能对外提供服务，否则会违背一致性（因为可能会访问到尚未同步的节点，此时读到的数据就不一致了）。

高可用性（Availability）

每次请求都能获得一个（非错误）响应，但不保证返回的是最新写入的数据。如果不能保证每次请求都能获取（非错误）响应，则不满足高可用性。
要求系统内的节点们接收到了无论是写请求还是读请求，都要能处理并给回响应结果。只是它有两点必须满足的条件：

• 条件 1：返回结果必须在合理的时间以内，这个合理的时间是根据业务来定的。业务说必须 100 毫秒内返回，合理的时间就是 100 毫秒，需要 1 秒内返回，那就是 1 秒，如果业务定的 100 毫秒，结果却在 1 秒才返回，那么这个系统就不满足可用性。
• 条件 2：需要系统内能正常接收请求的所有节点都返回结果。这包含了两重含义：如果节点不能正常接收请求了，比如宕机了，系统崩溃了，而其他节点依然能正常接收请求，那么，我们说系统依然是可用的，也就是说，部分宕机没事儿，不影响可用性指标。如果节点能正常接收请求，但是发现节点内部数据有问题，那么也必须返回结果，哪怕返回的结果是有问题的。比如，系统有两个节点，其中有一个节点数据是三天前的，另一个节点是两分钟前的，如果，一个读请求跑到了包含了三天前数据的那个节点上，抱歉，这个节点不能拒绝，必须返回这个三天前的数据，即使它可能不太合理。

分区容错性（Partition tolerance）

尽管任意数量的消息被节点间的网络丢失（或延迟），系统仍继续运行。
分布式的存储系统会有很多的节点，这些节点都是通过网络进行通信。而网络是不可靠的，当节点和节点之间的通信出现了问题，此时，就称当前的分布式存储系统出现了分区。但是，值得一提的是，分区并不一定是由网络故障引起的，也可能是因为机器故障。

三、CAP怎么选？

在分布式系统内，P 是必然的发生的，不选 P，一旦发生分区错误，整个分布式系统就完全无法使用了，这是不符合实际需要的。所以，对于分布式系统，我们只能能考虑当发生分区错误时，如何选择一致性和可用性。

一般选择：

• CA：传统Oracle数据库。
• AP：大多数网站架构的选择。
• CP：Redis、Mongodb。

资料：
https://www.zhihu.com/question/54105974
https://evanwang.blog.csdn.net/article/details/97186930?spm=1001.2014.3001.5502