CAP理论

什么是CAP

CAP原则又称CAP定理，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性）这三个基本需求，多只能同时满足其中的2个。

一致性 ：数据在多个副本之间能够保持一致的特性。
可用性：系统提供的服务一直处于可用的状态，每次请求都能获得正确的响应。
分区容错性：分布式系统在遇到任何网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。

什么是分区？

在分布式系统中，不同的节点分布在不同的子网络中，由于一些特殊的原因，这些子节点之间出现了网络不通的状态，但他们的内部子网络是正常的。从而导致了整个系统的环境被切分成了若干个孤立的区域，这就是分区。

为什么三者不可得兼

首先，我们得知道，分布式系统，是避免不了分区的，分区容错性是一定要满足的，我们看看在满足分区容错的基础上，能不能同时满足一致性和可用性？

假如现在有两个分区N1和N2，N1和N2分别有不同的分区存储D1和D2，以及不同的服务S1和S2。

在满足一致性 的时候，N1和N2的数据要求值一样的，D1=D2。
在满足可用性的时候，无论访问N1还是N2，都能获取及时的响应。

好的，现在有这样的场景：

用户访问了N1，修改了D1的数据。
用户再次访问，请求落在了N2。此时D1和D2的数据不一致。

接下来：

保证一致性：此时D1和D2数据不一致，要保证一致性就不能返回不一致的数据，可用性无法保证。
保证可用性：立即响应，可用性得到了保证，但是此时响应的数据和D1不一致，一致性无法保证。

所以，可以看出，分区容错的前提下，一致性和可用性是矛盾的。

CAP原则权衡

CAP三者不可同得，那么必须得做一些权衡。

CA without P❌

如果不要求P（不允许分区），则C（强一致性）和A（可用性）是可以保证的。但是对于分布式系统，分区是客观存在的，其实分布式系统理论上是不可选CA的。

CP without A

如果不要求A（可用），相当于每个请求都需要在Server之间强一致，而P（分区）会导致同步时间无限延长，如此CP也是可以保证的。很多传统的数据库分布式事务都属于这种模式。

AP wihtout C

要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。现在众多的NoSQL都属于此类。

CAP原则实际应用

我们应该都接触过微服务，常见的可以作为注册中心的组件有：ZooKeeper、Eureka、Nacos...。

ZooKeeper 保证的是 CP。 任何时刻对 ZooKeeper 的读请求都能得到一致性的结果，但是， ZooKeeper 不保证每次请求的可用性比如在 Leader 选举过程中或者半数以上的机器不可用的时候服务就是不可用的。
Eureka 保证的则是 AP。 Eureka 在设计的时候就是优先保证 A （可用性）。在 Eureka 中不存在什么 Leader 节点，每个节点都是一样的、平等的。因此 Eureka 不会像 ZooKeeper 那样出现选举过程中或者半数以上的机器不可用的时候服务就是不可用的情况。Eureka 保证即使大部分节点挂掉也不会影响正常提供服务，只要有一个节点是可用的就行了。只不过这个节点上的数据可能并不是新的。
Nacos 不仅支持 CP 也支持 AP。

BASE理论

什么是BASE理论

BASE 是 Basically Available（基本可用） 、Soft-state（软状态） 和 Eventually Consistent（终一致性） 三个短语的缩写。

BASE 理论是对 CAP 中一致性 C 和可用性 A 权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于 CAP 定理逐步演化而来的，它大大降低了我们对系统的要求。

BASE理论的核心思想是：

即使无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到终一致性（Eventual consistency）。

BASE理论的三个特性

基本可用

什么是基本可用呢？

假如系统出现了不可预知故障，允许损失部分可用性，当然也不能完全不可用。

损失的这部分可用性指的是什么？

响应时间上的损失：正常情况下的搜索引擎0.5秒即返回给用户结果，而基本可用的搜索引擎可以在2秒作用返回结果。
功能上的损失：在一个电商网站上，正常情况下，用户可以顺利完成每一笔订单。但是到了大促期间，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。

软状态

软状态指允许系统中的数据存在中间状态（CAP 理论中的数据不一致），并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。

终一致性

终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，终能够达到一个一致的状态。因此，终一致性的本质是需要系统保证终数据能够达到一致，而不需要实时保证系统数据的强一致性。

分布式一致性的 3 种级别：

强一致性 ：系统写入了什么，读出来的就是什么。

弱一致性 ：不一定可以读取到新写入的值，也不保证多少时间之后读取到的数据是新的，只是会尽量保证某个时刻达到数据一致的状态。

终一致性 ：弱一致性的升级版，系统会保证在一定时间内达到数据一致的状态。

业界比较推崇是终一致性级别，但是某些对数据一致要求十分严格的场景比如银行转账还是要保证强一致性。

终一致性怎么保证呢？

读时修复 : 在读取数据时，检测数据的不一致，进行修复。比如 Cassandra 的 Read Repair 实现，具体来说，在向 Cassandra 系统查询数据的时候，如果检测到不同节点的副本数据不一致，系统就自动修复数据。

写时修复 : 在写入数据，检测数据的不一致时，进行修复。比如 Cassandra 的 Hinted Handoff 实现。具体来说，Cassandra 集群的节点之间远程写数据的时候，如果写失败就将数据缓存下来，然后定时重传，修复数据的不一致性。

异步修复 : 这个是常用的方式，通过定时对账检测副本数据的一致性，并修复。