这两个理论都是对于分布式系统设计而言的。
CAP：Consistency(一致性),Availability(可用性),Partition Tolerance(分区容错)。这三个的单词的首字母组合。
BASE:Basically Available(基本可用),Soft-state(软状态),Eventually Consistent(最终一致性)三个短语的缩写。BASE理论是对CAP中一致性和可用性权衡的结果。其来源对于大规模互联网系统分布式实践的总结。是基于CAP定理逐渐演化而来的。它大大降低了我们对系统的要求。
CAP理论
CAP理论起源于2000年。是布鲁尔提出的。因此又被称为布鲁尔理论。
简介
CAP也就是Consistency(一致性)，Availability(可用性)，Partition Tolerance(分区容错性)这三个单词首字母组合。
CAP
其实最开始提出CAP猜想的时候，并没有详细定义三个单词的明确定义。所以这个解读有多种，下面是一种比较常见的解读：
- 一致性：所有节点访问同一份最新的数据副本
- 可用性：非故障的节点在合理的时间内返回合理的响应(不是错误或超时的响应)
- 分区容错性：分布式系统出现网络分区的时候，仍然能够对外提供服务。
什么是网络分区？
分布式系统中，多个节点之间的网络本来是可以连通的，但是因为某些故障(比如部分节点网络出现问题)某些节点不连通了，整个网络就分成几块区域，这就叫网络分区。
不是所谓的三选二
其实cap不是只能实现三个中的两个。而是分区容错是基础，而C,A是二选一的。因为我们任何情况下都不能去实现客观的不可能。比如服务器爆炸，服务器被摒弃网络信号，服务器着火种种，这些是没办法去控制的。所以网络分区之后，P是前提。一致性和可用性只能二选一。
因此分布式系统理论上不可能选择CA架构，只能选择CP或者AP架构。
比如zookeeper，hbase就是CP架构，C阿萨Sandra，Eureka就是AP架构。Nacos不仅支持CP架构也支持AP架构。
为啥不能选择CA架构呢？举个例子：若系统出现分区，某个节点正在进行写操作。为了保证一致性，必须禁止其他节点的读写操作。但是这就和可用性冲突了。如果为了保证可用性，其他节点正常读写的话，又和一致性冲突了。’
选择CP还是AP的关键在于业务场景，没有定论。对于需要确保强一致性的场景，比如银行一般会保证CP。
另外其实如果网络分区正常的话，也就是P没有出现问题，那么A和C是可以同时保证的。
CAP实际应用案例
注册中心负责服务地址的注册与查找。相当于目录服务。服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小。
注册中心
常见的可以作为注册中心的组件有：zookeeper，euraka，nacos。
- ZooKeeper：保证的是CP。任何时刻对zookeeper的读请求都能得到一致性的结果。但是zookeeper不保证每次请求的可用性。比如在leader选举过程中或者半数以上机器不可用的时候服务就是不可用的。
- Eureka保证的是AP。Eureka在设计的时候就是优先保证可用性。在Eureka中不存在什么Leader节点。每个节点都是一样的，平等的。因此Eureka不会像zookeeper那样出现选举过程中或者半数以上机器不可用的时候服务就不可用。Eureka保证即使大部分节点挂掉也不会影响正常提供服务，只要有一个节点可用就行，但是这个节点上的数据可能不是最新的。
- Nacos不仅支持CP也支持AP。
总结
其实在分布式系统设计和开发的时候，我们不应该仅仅局限于CAP的问题，还要关注系统的扩展性，可用性等。
在系统发生网络分区的情况下，CAP理论只能满足CP或者AP。但是如果没有发生网络分区，其实C,A是可以同时保证的。
所以说，如果发生网络分区，我们要考虑CP还是AP。如果没有网络分区，我们要考虑如何保证CA。
其实这个CAP我觉得可以认为是一个选择题。用生活中一个比喻来说：对一个小孩子来说，如果父母离婚，是跟爸爸还是跟妈妈。
首先前提要父母离婚，所以才会有接下来的选择(CAP中前提出现了网络分区，才会有一致性和可用性的选择)
然后跟妈妈还是爸爸只能是二选一的(出现P以后，A和C只能选一个)
至于到底跟谁，其实都要根据实际情况来看。而我们到底选择哪个自然也要看我们更在意什么。
比如银行转账，如果出现了P，保证可用性而放弃一致性的话。A转给B100元钱。A这边少100.但是因为B那边网不通，B没有多一百。 这样100块钱蒸发了。这样肯定不行，所以我们完全可以在出现P以后，保证一致性而放弃可用性，不让A转账了。这样哪怕A不乐意不开心，但是整体的逻辑是对的。
而对于别的场景，比如说浏览视频点赞，这个时候出现了网络分区，你这边点了可能服务器记录不上。但是这又不妨碍让用户先点着，最多最多最后数据丢失了，那估计用户还会以为自己记错了而已。所以这个时候我们完全可以选择可用性而不是一致性。
另外CAP其实可以认为是个预想中的场景。正常来说P是不会出现的，可是我们在做程序要预测到可能出现的bug。所以哪怕说Euraka选择了AP，但是也没总出现什么数据不一致，zookeeper选择了CP，但是大部分时间也都是可用的。
BASE理论
BASE理论起源于2008年。
简介
BASE是Basically Available(基本可用)，Soft-state(软状态)和Eventually Consistent(最终一致性)三个短语组成。BASE理论是对CAP中一致性和可用性权衡的结果。其来源于对大规模互联网系统分布式实践的总结。是基于CAP定理逐渐演化而来的，它大大降低了我们对系统的要求。
BASE理论的核心思想
即使无法做到强一致性，但是每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。
也就是牺牲数据的一致性来满足系统的高可用性。系统中一部分数据不可用或者不一致时，仍需要保持系统整体主要可用。
其实BASE可以看成是CAP中关于AP的一个补充。AP方案是放弃一致性选择可用性。但是只是在系统发生分区的时候放弃一致性，而不是永久放弃。所以在分区故障恢复后，系统最终应该还是要达到一致性的。这就是BASE理论延申的地方。
BASE理论三要素
BASE
-
基本可用
基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性。但是这决不等于系统不可用。
什么叫允许损失部分可用性呢?- x响应时间上的损失：正常情况下0.1s返回结果，但是由于系统故障，变成1s返回结果了。
- 系统功能上的损失：正常情况下用户可以使用系统的全部功能，但是由于访问量剧增，系统的部分非核心功能无法使用。
-
软状态
软状态指允许系统中的数据存在中间状态(CAP理论中的数据不一致)，并认为该中间状态不会影响系统的整体可用性。即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。 -
最终一致性
最终一致性强调的是系统中所有的数据副本，经历过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据一致而不是实时强一致。
分布式一致性的三种级别：
- 强一致性：系统写入什么读出来的就是什么
- 弱一致性：不一定读取到的是最新的值，也不保证多长时间后读到的数据是最新的。只会尽量保证某个时刻达到数据一致的状态
- 最终一致性：弱一致性的升级版，系统会保证在一定时间内达到数据一致的状态。
目前在要求不严格的情况，比较常见的还是最终一致性级别。
实现最终一致性的具体方式是什么？
- 读时修复:在读取数据时，检测数据不一致，进行修复。比如在查询的时候如果检测到不同节点的副本数据不一致，则自动修复数据。
- 写时修复:在写入数据的时候，检测数据的不一致时，进行修复。如果写失败了就将数据缓存下来，然后定时重传，修复数据的不一致性。
- 异步修复:这个是最常用的方式，通过定时对账，检测副本数据的一致性并修复。
比较推荐写时修复，这种方式对性能消耗比较低。
本篇笔记就记到这里，如果稍微帮到你了记得点个喜欢点个关注，也祝大家工作顺顺利利！
网友评论