cap（CAP和BASE理论了解么？）

　　来源：https：mp。weixin。qq。coms0qelIYKkyNVsM29u3yH1w
　　经历过技术面试的小伙伴想必对这个两个概念已经再熟悉不过了！
　　CAP理论
　　CAP理论定理起源于2000年，由加州大学伯克利分校的EricBrewer教授在分布式计算原理研讨会（PODC）上提出，因此CAP定理又被称作布鲁尔定理（Brewer’stheorem）
　　2年后，麻省理工学院的SethGilbert和NancyLynch发表了布鲁尔猜想的证明，CAP理论正式成为分布式领域的定理。
　　简介
　　CAP也就是Consistency（一致性）、Availability（可用性）、PartitionTolerance（分区容错性）这三个单词首字母组合。
　　CAP理论的提出者布鲁尔在提出CAP猜想的时候，并没有详细定义Consistency、Availability、PartitionTolerance三个单词的明确定义。
　　因此，对于CAP的民间解读有很多，一般比较被大家推荐的是下面这种版本的解。
　　在理论计算机科学中，CAP定理（CAPtheorem）指出对于一个分布式系统来说，当设计读写操作时，只能能同时满足以下三点中的两个：
　　一致性（Consistence）：所有节点访问同一份最新的数据副本可用性（Availability）：非故障的节点在合理的时间内返回合理的响应（不是错误或者超时的响应）。分区容错性（Partitiontolerance）：分布式系统出现网络分区的时候，仍然能够对外提供服务。
　　什么是网络分区？
　　分布式系统中，多个节点之前的网络本来是连通的，但是因为某些故障（比如部分节点网络出了问题）某些节点之间不连通了，整个网络就分成了几块区域，这就叫网络分区。
　　partitiontolerance
　　不是所谓的3选2
　　大部分人解释这一定律时，常常简单的表述为：一致性、可用性、分区容忍性三者你只能同时达到其中两个，不可能同时达到。实际上这是一个非常具有误导性质的说法，而且在CAP理论诞生12年之后，CAP之父也在2012年重写了之前的论文。
　　当发生网络分区的时候，如果我们要继续服务，那么强一致性和可用性只能2选1。也就是说当网络分区之后P是前提，决定了P之后才有C和A的选择。也就是说分区容错性（Partitiontolerance）我们是必须要实现的。
　　简而言之就是：CAP理论中分区容错性P是一定要满足的，在此基础上，只能满足可用性A或者一致性C。
　　因此，分布式系统理论上不可能选择CA架构，只能选择CP或者AP架构。
　　为啥无同时保证CA呢？
　　举个例子：若系统出现分区，系统中的某个节点在进行写操作。为了保证C，必须要禁止其他节点的读写操作，这就和A发生冲突了。如果为了保证A，其他节点的读写操作正常的话，那就和C发生冲突了。
　　选择的关键在于当前的业务场景，没有定论，比如对于需要确保强一致性的场景如银行一般会选择保证CP。
　　CAP实际应用案例
　　我这里以注册中心来探讨一下CAP的实际应用。考虑到很多小伙伴不知道注册中心是干嘛的，这里简单以Dubbo为例说一说。
　　下图是Dubbo的架构图。注册中心Registry在其中扮演了什么角色呢？提供了什么服务呢？
　　注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小。
　　常见的可以作为注册中心的组件有：ZooKeeper、Eureka、Nacos。。。。
　　ZooKeeper保证的是CP。任何时刻对ZooKeeper的读请求都能得到一致性的结果，但是，ZooKeeper不保证每次请求的可用性比如在Leader选举过程中或者半数以上的机器不可用的时候服务就是不可用的。Eureka保证的则是AP。Eureka在设计的时候就是优先保证A（可用性）。在Eureka中不存在什么Leader节点，每个节点都是一样的、平等的。因此Eureka不会像ZooKeeper那样出现选举过程中或者半数以上的机器不可用的时候服务就是不可用的情况。Eureka保证即使大部分节点挂掉也不会影响正常提供服务，只要有一个节点是可用的就行了。只不过这个节点上的数据可能并不是最新的。Nacos不仅支持CP也支持AP。总结
　　在进行分布式系统设计和开发时，我们不应该仅仅局限在CAP问题上，还要关注系统的扩展性、可用性等等。
　　在系统发生分区的情况下，CAP理论只能满足CP或者AP。要注意的是，这里的前提是系统发生了分区
　　如果系统没有发生分区的话，节点间的网络连接通信正常的话，也就不存在P了。这个时候，我们就可以同时保证C和A了。
　　总结：如果系统发生分区，我们要考虑选择CP还是AP。如果系统没有发生分区的话，我们要思考如何保证CA。
　　推荐阅读CAP定理简化（英文，有趣的案例）神一样的CAP理论被应用在何方（中文，列举了很多实际的例子）请停止呼叫数据库CP或AP（英文，带给你不一样的思考）BASE理论
　　BASE理论起源于2008年，由eBay的架构师DanPritchett在ACM上发表。
　　简介
　　BASE是BasicallyAvailable（基本可用）、Softstate（软状态）和EventuallyConsistent（最终一致性）三个短语的缩写。BASE理论是对CAP中一致性C和可用性A权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于CAP定理逐步演化而来的，它大大降低了我们对系统的要求。
　　BASE理论的核心思想
　　即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。
　　也就是牺牲数据的强一致性来满足系统的高可用性，系统中一部分数据不可用或者不一致时，仍需要保持系统整体主要可用。
　　BASE理论本质上是对CAP的延伸和补充，更具体地说，是对CAP中AP方案的一个补充。
　　为什么这样说呢？
　　CAP理论这节我们也说过了：
　　如果系统没有发生分区的话，节点间的网络连接通信正常的话，也就不存在P了。这个时候，我们就可以同时保证C和A了。因此，如果系统发生分区，我们要考虑选择CP还是AP。如果系统没有发生分区的话，我们要思考如何保证CA。
　　因此，AP方案只是在系统发生分区的时候放弃一致性，而不是永远放弃一致性。在分区故障恢复后，系统应该达到最终一致性。这一点其实就是BASE理论延伸的地方。
　　BASE理论三要素
　　BASE理论三要素
　　1。基本可用
　　基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性。但是，这绝不等价于系统不可用。
　　什么叫允许损失部分可用性呢？
　　响应时间上的损失：正常情况下，处理用户请求需要0。5s返回结果，但是由于系统出现故障，处理用户请求的时间变为3s。系统功能上的损失：正常情况下，用户可以使用系统的全部功能，但是由于系统访问量突然剧增，系统的部分非核心功能无法使用。2。软状态
　　软状态指允许系统中的数据存在中间状态（CAP理论中的数据不一致），并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
　　3。最终一致性
　　最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。
　　分布式一致性的3种级别：
　　强一致性：系统写入了什么，读出来的就是什么。
　　弱一致性：不一定可以读取到最新写入的值，也不保证多少时间之后读取到的数据是最新的，只是会尽量保证某个时刻达到数据一致的状态。
　　最终一致性：弱一致性的升级版。，系统会保证在一定时间内达到数据一致的状态，
　　业界比较推崇是最终一致性级别，但是某些对数据一致要求十分严格的场景比如银行转账还是要保证强一致性。
　　总结
　　BASE理论这块的话还可以结合分布式事务来谈。相关阅读：阿里终面：分布式事务原理
　　ACID是数据库事务完整性的理论，CAP是分布式系统设计理论，BASE是CAP理论中AP方案的延伸。