一.前言

小知识，大挑战！本文正在参与“程序员必备小知识”创作活动。

本文已参与「掘力星计划」，赢取创作大礼包，挑战创作激励金。

hello，everyone。一个月没有写博客了，都不知道该写点啥了哈哈哈。金九银十，年底了，各个公司都开放出了大量的HC，你准备跳槽了吗？

最近一个月博主也为了保持面试的感觉面了几个中大厂，也都拿到了offer。总结了一下面试的过程，发现有好多八股文或者问题，不论是小厂，中厂，大厂都是很喜欢问的。

如果大家对面试相关的问题与技巧感兴趣的话，可以在本文或者公众号【柏炎大叔】给我留言，我可以出几篇文章专门为大家介绍一下。

本文将会给大家介绍一下分布式理论相关的知识。不说让你看完这篇文章精通分布式理论，但至少你可以正面对战面试官。

坐稳发车了~

二.CAP

分布式理论中，我碰到过最多的协议就是CAP。机会面试10次，至少会碰到3-4个面试官会问这个问题：你了解CAP理论吗？

2.1.概念

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

选项	描述
Consistency（一致性）	指数据在多个副本之间能够保持一致的特性（严格的一致性）
Availability（可用性）	指系统提供的服务必须一直处于可用的状态，每次请求都能获取到非错的响应（不保证获取的数据为最新数据）
Partition tolerance（分区容错性）	分布式系统在遇到任何网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务，除非整个网络环境都发生了故障

2.2.CAP为什么不可同时满足

看完上面的概念知识，我们来理解一下：三个基本需求，最多只能同时满足其中两个。

假设我们现在有一个电商网站，分布式异地部署。在上海与北京分别部署了两台服务器，均为独立的数据节点。用户请求域名进入CDN加速解析根据地域分别路由。南方路由到上海，北方路由到北京。并且两地的数据进行后台异步同步。

那么这里会存在什么问题呢？

分布式理论下一般情况都要满足P，那么在P为前提的情况下只能满足CP或者AP了。这个怎么看呢？

举例：

假设现在上海服务器所在机房出现了不可逆的地质灾害或者停电【比如前不久小破站出现的down机情况，哈哈】。

AP

在高并发情况下，上海节点部分业务数据还没有同步到北京的数据库中，此时为了保证高可用A的特性，则将请求转发到北京，牺牲了数据一致性C。

CP

但是比如银行转账这种强金融业务，数据一致性是很重要的，我转出去多少钱，别人就一定要收到多少钱。此时为了保证数据一致性，就要牺牲可用性了。因为你的转账数据节点是在上海的，如果这时路由转账数据至背景节点，数据就出现了不一致。

2.3.CP与AP怎么选择？

CAP不可同时满足，P又一定要保证，那么我们是选择CP还是选择AP呢？

对于多数大型互联网应用的场景，主机众多、部署分散。而且现在的集群规模越来越大，所以节点故障、网络故障是常态。比如电商网站浏览数据，如果部分节点挂了，肯定不会说不让你浏览商品了。你会明显的感受到数据加载数据变慢了【据说昨天双十一预售把淘宝干挂了，淘系的朋友们还好吗？3.25警告了！】，但是最终数据还是能加载出来。

当然如果涉及到金钱的系统，C是必须保证的。所以一般情况下金融系统都会选择后半夜发布，并且在发布的时候会增加提示语说系统升级，可能会导致部分功能不可用。这就是为了保证数据的一致性，牺牲了系统的可用性。

因此，CP好还是AP好这个是没有一个绝对的结论的，需要根据实际的场景来决定使用哪个理论。

2.4.各种中间件使用什么理论

单节点mysql使用CA

单节点的数据库就是典型是的使用CA原则，抛弃分区容错，保障了ACID特性。在数据库可用的同时保证了数据一致性。

zookeeper选择CP

zookeepr保证CP，即任何时刻对zookeeper的访问请求能得到一致性的数据结果，同时系统对网络分割具备容错性，但是它不能保证每次服务的可用性。从实际情况来分析，在使用zookeeper获取服务列表时，如果zk正在选举或者zk集群中半数以上的机器不可用，那么将无法获取数据。所以说，zk不能保证服务可用性。

eureka选择AP

eureka保证AP，eureka在设计时优先保证可用性，每一个节点都是平等的，一部分节点挂掉不会影响到正常节点的工作，不会出现类似zk的选举leader的过程，客户端发现向某个节点注册或连接失败，会自动切换到其他的节点，只要有一台eureka存在，就可以保证整个服务处在可用状态，只不过有可能这个服务上的信息并不是最新的信息。

nacos支持CP，也支持AP

与zookeepr,eureka不同的是，nacos既支持CP与AP

nacos会根据不同的实例类型选择不同的架构

spring:
  cloud:
    nacos:
      discovery:
        server-addr: 127.0.0.1:8848
        group:  baiyan
        cluster-name: BAIYAN
        ephemeral: false   //持久化实例，使用 CP架构
        ephemeral: true    //临时实例，使用 AP架构

1. 临时实例，选择AP架构，使用Distro协议，分布式协议的一种，阿里内部的协议，服务是放在内存中
2. 持久实例，选择CP架构，使用Raft协议来实现，点击查看Raft协议详情！服务是放在磁盘中

redis集群

通过自动分片和冗余数据，Redis具有了真正的分布式能力，某个结点挂了的话，因为数据在其他结点上有备份，所以其他结点顶上来就可以继续提供服务，保证了Availability。然而，也正因为这一点，Redis无法保证曾经的强一致性了。这也是CAP理论要求的，三者只能取其二。

mysql主从

与redis类似，一主多从，不保证数据数据节点同步的实时性，保证数据吞吐量使用AP，保证主从同步一致则使用CP.

kafka集群

Kafka的数据复制方案接近于Master-Slave，不同的是，Kafka既不是完全的同步复制，也不是完全的一步复制，而是基于ISR的动态复制方案。

只有被ISR中所有Replica同步的消息才被commit，但是Producer在写数据时，Leader不需要ISR中所有Replica同步该数据才确认收到数据。 Producer可以通过acks参数指定最少需要多少个Replica确认收到该消息才视为该消息发送成功。acks默认值为1，即Leader收到该消息后立即告诉Producer收到该消息，此时如果在ISR中的消息复制完该消息前Leader宕机，那该条消息会丢失。推荐做法是：将acks设置为all或-1，此时只有ISR中的所有Replica都收到该数据（也及消息被commit），Leader才会告诉Producer该消息发送成功，这样保证了不会有未知的数据丢失。

可以根据对于kafka的吞吐量的需求自由选择使用AP还是CP。

2.5.小结

CAP是一个纯理论层面的概念知识。但是很多中间件或者很多业务系统都是以这个理论为基础构建了分布式应用体系。CP与AP没有最好之分，只有场景合适之分。

三.BASE

印象中,BASE理论我在面试中没有碰到过，但是它的理论地位跟CAP是一样的，对于接触分布式开发的同学来说是不可或缺的。

3.1.概念

BASE理论是Basically Available(基本可用)，Soft State（软状态）和Eventually Consistent（最终一致性）三个短语的缩写。

BASE是对CAP中一致性和可用性权衡的结果，是基于CAP定律逐步演化而来。其核心思想是即使无法做到强一致性，但每个应用都可以根据自身业务特点，才用适当的方式来使系统达到最终一致性。

3.1.1.基本可用

假设系统，出现了不可预知的故障，但还是能用，相比较正常的系统而言：

响应时间上的损失：

正常情况下的商品展示页面0.5秒即返回给用户结果，而基本可用的商品页面可以在2秒左右返回结果。

功能上的损失：

【正常】 在一个电商网站上，正常情况下，用户可以顺利完成每一笔订单。

【限流】 但是到了大促期间，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。

【降级】 又或是为了保障系统的核心功能可用，暂停部分非核心功能，例如双十一大促时，不支持回溯较早事件的账单数据。

3.1.2. 软状态

允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。

举例

比如redis主从节点数据复制。在某一瞬间，主从节点数据同步，存在数据不一致的情况。

3.1.3. 最终一致性

上面说软状态，然后不可能一直是软状态，必须有个时间期限。在期限过后，应当保证所有副本保持数据一致性，从而达到数据的最终一致性。这个时间期限取决于网络延时、系统负载、数据复制方案设计等等因素。

举例

还是上面的redis主从数据复制，在流量高峰过去之后，主从复制效率提升，最终主从节点数据一致。

3.2.BASE理论到底什么用？

CAP原则是三选二，BASE原则是CAP的折中，C,A,P三个都要，但不用100%的保证每一个原则。分布式系统肯定优先保证P，多数时候是在C和A之间做权衡选择。

满足AP的系统在一定程度上也可以说是符合 BASE原则的，比如eurka集群，三个节点挂了两个，系统还是基本可用的（BA）。此时如果有系统来注册了，因为挂了两个节点，这时整个系统各个节点的数据是不一致的，但是等挂掉的两个节点恢复了，数据会同步过去，保证最终一致性（E），对于中间数据暂时不一致的状态可以称为软状态（S）。

总的来说，BASE理论面向的是大型高可用可扩展的分布式系统，和传统的事物ACID特性是相反的，它完全不同于ACID的强一致性模型，而是通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态。

四.面试真题

1.说一下CAP理论？

2.nacos在作为注册中心与配置中心的时候分别怎么选用协议，说一下原因？

3.你知道的分布式协议是什么【Paxos，Raft】，有哪些中间件使用到了？

4.CP,AP,CA分别选择的标准是什么？

1，2，4答案在文中都已经给出了，Paxos，Raft协议问到的比较少，感兴趣的可以自行百度一下。

五.小结

不管是CAP还是BASE，最终目的都是为了保障系统在分布式情况数据的一致性或者可用性。当然鱼和熊掌不可兼得，根据不同系统在不同业务场景下的不同定位，可以选择不同的方式去实现分布式架构。

六.参考

分布式理论(一) - CAP定理

分布式理论(二) - BASE理论

Nacos集群的CP架构，CAP原则与BASE原则的应用

七.联系我

文中如有不正确之处，欢迎指正，写文不易，点个赞吧，么么哒~

钉钉：louyanfeng25

微信：baiyan_lou

公众号：柏炎大叔