互联网寒冬，面试越来越卷了，老司机都知道，现在基本上都会问到分布式的内容，所以我们非常之有必要掌握分布式理论知识。CAP与BASE理论重要程度5颗星。
创作不易，你的关注分享就是博主更新的最大动力， 每周持续更新
微信搜索【 **企鹅君】**关注还能领取学习资料喔，第一时间阅读(比博客早两到三篇)
求关注❤️ 求点赞❤️ 求分享❤️ 对博主真的非常重要
该篇已经被GitHub项目收录github.com/JavaDance 欢迎Star和完善
CAP理论
CAP 是 Consistency（一致性）、Availability（可用性）、Partition Tolerance（分区容错性） 这三个单词首字母组合。
Consistency(一致性)：
对于客户端的每次读操作，要么读到的是最新的数据，要么读取失败。换句话说，一致性是站在分布式系统的角度，对访问本系统的客户端的一种承诺：要么我给您返回一个错误，要么我给你返回绝对一致的最新数据，不难看出，其强调的是数据正确。
Availability(可用性)：
任何客户端的请求都能得到响应数据，不会出现响应错误。换句话说，可用性是站在分布式系统的角度，对访问本系统的客户的另一种承诺：我一定会给您返回数据，不会给你返回错误，但不保证数据最新，强调的是不出错。
Partition Tolerance(分区容忍性)：
由于分布式系统通过网络进行通信，网络是不可靠的。当任意数量的消息丢失或延迟到达时，系统仍会继续提供服务，不会挂掉。换句话说，分区容忍性是站在分布式系统的角度，对访问本系统的客户端的再一种承诺：我会一直运行，不管我的内部出现何种数据同步问题，强调的是不挂掉。
CAP 理论指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。但由于在分布式系统中，分区容错性必然存在，所以只能在一致性和可用性妥协
权衡 C、A
note：其实这里有个关于CAP理论理解的误区。不要以为在所有时候都只能选择两个特性。在不存在网络失败的情况下（分布式系统正常运行时），C和A能够同时保证。只有当网络发生分区或失败时，才会在C和A之间做出选择。
对于一个分布式系统而言，P是前提，必须保证，因为只要有网络交互就一定会有延迟和数据丢失，这种状况我们必须接受，必须保证系统不能挂掉。所以只剩下C、A可以选择。要么保证数据一致性（保证数据绝对正确），要么保证可用性（保证系统不出错）。
当选择了C（一致性）时，如果由于网络分区而无法保证特定信息是最新的，则系统将返回错误或超时。
当选择了A（可用性）时，系统将始终处理客户端的查询并尝试返回最新的可用的信息版本，即使由于网络分区而无法保证其是最新的。
服务注册中心，是选择AP还是选择CP ？
服务注册中心解决的问题
在讨论CAP之前先明确下服务注册中心主要是解决什么问题：一个是服务注册，一个是服务发现。
- 服务注册：实例将自身服务信息注册到注册中心，这部分信息包括服务的主机IP和服务的Port，以及暴露服务自身状态和访问协议信息等。
- 服务发现：实例请求注册中心所依赖的服务信息，服务实例通过注册中心，获取到注册到其中的服务实例的信息，通过这些信息去请求它们提供的服务。
目前作为注册中心的一些组件大致有：dubbo的zookeeper，springcloud的eureka，consul，rocketMq的nameServer，hdfs的nameNode。目前微服务主流是dubbo和springcloud，使用最多是zookeeper和eureka，我们就来看看应该根据CAP理论应该怎么去选择注册中心。（springcloud也可以用zk，不过不是主流不讨论）。
zookeeper选择CP
zookeep保证CP，即任何时刻对zookeeper的访问请求能得到一致性的数据结果，同时系统对网络分割具备容错性，但是它不能保证每次服务的可用性。从实际情况来分析，在使用zookeeper获取服务列表时，如果zk正在选举或者zk集群中半数以上的机器不可用，那么将无法获取数据。所以说，zk不能保证服务可用性。
eureka选择AP
eureka保证AP，eureka在设计时优先保证可用性，每一个节点都是平等的，一部分节点挂掉不会影响到正常节点的工作，不会出现类似zk的选举leader的过程，客户端发现向某个节点注册或连接失败，会自动切换到其他的节点，只要有一台eureka存在，就可以保证整个服务处在可用状态，只不过有可能这个服务上的信息并不是最新的信息。
BASE理论
对于 CAP 来说，放弃强一致性，追求分区容错性和可用性，是很多分布式系统设计时的选择。在工程实践中，基于 CAP 定理逐步演化，出现了 Base 理论。
Base 是三个短语的简写，即基本可用（Basically Available）、软状态（Soft State）和最终一致性（Eventually Consistent）。
Base 理论的核心思想是最终一致性，即使无法做到强一致性（Strong Consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual Consistency）。
1、基本可用（Basically Available）
基本可用比较好理解，就是不追求 CAP 中的「任何时候，读写都是成功的」，而是系统能够基本运行，一直提供服务。基本可用强调了分布式系统在出现不可预知故障的时候，允许损失部分可用性，相比正常的系统，可能是响应时间延长，或者是服务被降级。
举个例子，在双十一秒杀活动中，如果抢购人数太多超过了系统的 QPS 峰值，可能会排队或者提示限流，这就是通过合理的手段保护系统的稳定性，保证主要的服务正常，保证基本可用。
2、软状态（Soft State）
软状态可以对应 ACID 事务中的原子性，在 ACID 的事务中，实现的是强制一致性，要么全做要么不做，所有用户看到的数据一致。其中的原子性（Atomicity）要求多个节点的数据副本都是一致的，强调数据的一致性。
原子性可以理解为一种“硬状态”，软状态则是允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。
3、最终一致性（Eventual Consistency）
数据不可能一直是软状态，必须在一个时间期限之后达到各个节点的一致性，在期限过后，应当保证所有副本保持数据一致性，也就是达到数据的最终一致性。
在系统设计中，最终一致性实现的时间取决于网络延时、系统负载、不同的存储选型、不同数据复制方案设计等因素。
BASE理论是对CAP中AP的一个扩展，通过牺牲强一致性来获得可用性，当出现故障允许部分不可用但要保证 核心功能可用，允许数据在一段时间内是不一致的，但最终达到一致状态。
行业内常用的就是最终一致性(AP)，但是对数据一致要求十分严格的场景比如支付转账还是要保证强一致性(CP)。
参考
创作不易，你的关注分享就是博主更新的最大动力， 每周持续更新
微信搜索【 **企鹅君】**关注还能领取学习资料喔，第一时间阅读(比博客早两到三篇)
求关注❤️ 求点赞❤️ 求分享❤️ 对博主真的非常重要
该篇已经被GitHub项目收录github.com/JavaDance 欢迎Star和完善
757
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
