cap与base(cap原理和base思想)

　　cap与base(cap原理和base思想)，新营销网红网本栏目通过数据整理汇集了cap与base(cap原理和base思想)相关信息，下面一起看看。

　　经历过技术面试的朋友一定对这两个概念很熟悉！

　　理论上限理论(theory CAP theory/theory)起源于2000年，由加州大学柏克莱分校的Eric Brewer教授在分布式计算原理研讨会(PODC)上提出。所以CAP定理也叫布鲁尔定理。

　　两年后，麻省理工的Seth Gilbert和Nancy Lynch发表了Brewer猜想的证明，CAP理论正式成为分布式场的定理。

　　简介CAP是一致性、可用性和分区容差首字母组合。

　　 CAP理论的创始人Brewer在提出CAP猜想时，并没有详细定义一致性、可用性和划分容忍度。

　　所以民间对CAP的解读很多。一般大家推荐以下版本的解决方案。

　　在理论计算机科学中，CAP定理指出，对于分布式系统，在设计读写操作时，只能满足以下三点中的两点

　　一致性):所有节点访问相同的最新数据副本。

　　可用性):非故障节点在合理的时间内返回合理的响应(不是错误或超时响应)。

　　分区容忍度):分布式系统在网络分区发生时，仍能向外界提供服务。

　　什么是网络分区？

　　在分布式系统中，多个节点之前的网络是连通的，但由于某些节点由于某种故障而断开连接(例如某些节点出现网络问题)，整个网络被分成若干区域，这种情况称为网络分区。

　　分区容差

　　并不是所谓的“3中2”。大多数人在解释这个定律时，往往简单地表述为“一致性、可用性和分区容忍度只能由其中两个达到，而不能达到”。其实这是一个非常误导人的说法，在CAP理论诞生12年后，CAP之父在2012年重写了之前的论文。

　　当网络分区发生时，如果我们要继续服务，那么强一致性和可用性只能是1比2。也就是说，网络划分后，P是前提，P确定后，可以选择C和A。也就是说，我们必须实现分区容忍。

　　简言之，必须满足CAP理论中的分区容错P，在此基础上，只能满足可用性A或一致性c。

　　所以分布式系统理论上不可能选择CA架构，只能选择CP或者AP架构。

　　为什么不保证CA？

　　例如，如果系统被分区，则系统中的一个节点正在写入。为了保证C，必须禁止其他节点的读写操作，这就和A冲突了，如果为了保证A，其他节点正常读写，就和C冲突了。

　　选择的关键在于目前的商业场景，这是没有定论的。比如，对于需要保证强一致性的场景，银行一般会选择担保CP。

　　 CAP的实际应用案例我在这里和注册中心讨论一下CAP的实际应用。考虑到很多小伙伴不知道注册中心是干什么的，这里简单举个Dubbo的例子。

　　下图是Dubbo的架构图。注册表在其中扮演什么角色？提供什么服务？

　　注册中心负责服务地址的注册和查找，相当于目录服务。服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较低。

　　可以用作注册中心的常见组件有ZooKeeper、Eureka、Nacos.

　　 ZooKeeper保证CP。任何对ZooKeeper的读取请求都可以得到一致的结果，ZooKeeper并不保证每个请求的可用性。例如，在领导者选举过程中或当超过一半的机器不可用时，服务不可用。

　　尤里卡保证AP。尤里卡的设计优先考虑A(可用性)。尤里卡没有领袖节点，每个节点都是一样的，平等的。所以，尤里卡不会像ZooKeeper一样，在选举过程中服务不可用，或者超过一半的机器不可用。Eureka保证即使大部分节点挂机，也不会影响正常的服务提供，只要有一个节点可用。，此节点上的数据可能不是最新的。

　　 Nacos不仅支持CP，还支持AP。

　　，在设计和开发分布式系统时，不仅要关注CAP，还要关注可扩展性、可用性等。

　　当系统分块时，CAP理论只能满足CP或AP。注意这里的前提是系统是分区的。

　　如果系统中没有“分区”，节点之间的网络连接通信正常，就不会有p，这个时候我们就可以保证C和a。

　　如果系统分区，要考虑选择CP还是AP。如果系统中没有“分区”，就要思考如何保证CA。

　　推荐CAP定理的简化(英文，有意思

　　案例）

　　神一样的 CAP 理论被应用在何方 （中文，列举了很多实际的例子）

　　请停止呼叫数据库 CP 或 AP （英文，带给你不一样的思考）

　　BASE 理论

　　BASE 理论起源于 2008 年， 由 eBay 的架构师 Dan Pritchett 在 ACM 上发表。

　　简介

　　BASE是Basically Available（基本可用）、Soft-state（软状态）和Eventually Consistent（最终一致性）三个短语的缩写。BASE 理论是对 CAP 中一致性 C 和可用性 A 权衡的结果，其来源于对大规模互联网系统分布式实践的，是基于 CAP 定理逐步演化而来的，它大大降低了我们对系统的要求。

　　BASE 理论的核心思想

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

　　也就是牺牲数据的强一致性来满足系统的高可用性，系统中一部分数据不可用或者不一致时，仍需要保持系统整体“主要可用”。

　　BASE 理论本质上是对 CAP 的延伸和补充，更具体地说，是对 CAP 中 AP 方案的一个补充。

　　为什么这样说呢？

　　CAP 理论这节我们也说过了

　　如果系统没有发生“分区”的话，节点间的网络连接通信正常的话，也就不存在 P 了。这个时候，我们就可以保证 C 和 A 了。，如果系统发生“分区”，我们要考虑选择 CP 还是 AP。如果系统没有发生“分区”的话，我们要思考如何保证 CA 。

　　，AP 方案只是在系统发生分区的时候放弃一致性，而不是永远放弃一致性。在分区故障恢复后，系统应该达到最终一致性。这一点其实就是 BASE 理论延伸的地方。

　　BASE 理论三要素

　　BASE理论三要素

　　1. 基本可用

　　基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性。，这绝不等价于系统不可用。

　　什么叫允许损失部分可用性呢？

　　响应时间上的损失: 正常情况下，处理用户请求需要 0.5s 返回结果，由于系统出现故障，处理用户请求的时间变为 3 s。

　　系统功能上的损失正常情况下，用户可以使用系统的全部功能，由于系统访问量突然剧增，系统的部分非核心功能无法使用。

　　2. 软状态

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

　　3. 最终一致性

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

　　分布式一致性的 3 种级别

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

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

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

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

　　

　　BASE 理论这块的话还可以结合分布式事务来谈。相关阅读阿里终面分布式事务原理

　　ACID 是数据库事务完整性的理论，CAP 是分布式系统设计理论，BASE 是 CAP 理论中 AP 方案的延伸。

　　cap

　　更多cap与base(cap原理和base思想)相关信息请关注本文章，本文仅仅做为展示！