大家好，我是沐晨，先跟大家说一声元旦快乐！不知道大家元旦都干啥去了，反正我是家里蹲呢~
我们都知道，是否掌握分布式系统架构知识，是衡量一个后端开发人员技术实力的最高标准之一，其中的CAP理论和Base理论是整个架构系统的理论基石，也是众多一线互联网大厂面试必问的知识点。
但是网上很多关于这个知识点的讲解比较杂，看了半天总有种浅尝辄止的感觉，那我们今天就来彻底聊清楚这俩理论。
CAP理论
内容
1998年，加州大学的计算机科学家Eric Brewer提出：
在一个分布式系统中，不可能同时满足一致性、可用性、分区容错性，最多只能同时实现两点。**
由于一致性（Consistency）、可用性（Availability）、**分区容错性（Partition tolerance）**的英文单词首字母分别是C、A、P，因此该理论又称CAP理论。
一致性
含义
一般互联网公司会将数据复制多份存储，分布式系统更是这样。
一致性指的是：用户对数据的事务操作(增删改操作)要么在所有数据副本都执行成功，要么都失败，即满足原子性，这样任一数据节点的数据都应该是一致的。
场景举例
现在有一个主从架构的数据库，我们的应用程序要向主数据库写入数据，同时应用程序同时会向从数据库读取数据。
这种场景下要达到一致性要求指的是：
- 应用程序向主数据库写数据失败，则向从数据库读取数据也失败。
- 应用程序向主数据库写数据成功，则向从数据库读取数据也成功。
如果此时要保持一致性必须这样做：
- 应用程序将数据写入主数据库后，将数据同步到从数据库中。
- 数据写入数据库后，主数据库将数据同步到从数据库存在一定的时间延迟，这个过程需要将从数据库锁定，避免应用程序向从数据库中读取出与数据库不一致的数据。
- 待数据同步完成后再释放从数据库的锁。
可用性
含义
可用性的是：客户端访问数据的时候，能快速得到正常响应，不会存在超时或响应错误的情况。
场景举例
还是一样的场景：现在有一个主从架构的数据库，我们的应用程序要向主数据库写入数据，同时应用程序同时会向从数据库读取数据。
如果此时要保持可用性要求指的是：
- 应用程序读取从数据库数据时，从数据库能快速响应结果，不能出现响应超时或响应错误的情况
如果此时要保持可用性必须这样做：
- 主数据库同步数据到从数据库过程中，不能锁定从数据库的资源。
- 应用程序向从数据库查询数据的过程中一定要返回数据，即使该数据是旧数据，如果旧数据都没有则返回一个默认数据。
分区容错性
含义
如果将存储系统部署并运行在多个节点上，并且这些节点处于不同的网络中，这就形成了网络分区，此时会难免出现网络问题，导致节点之间的通信失败。
分区容错性指的是：出现网络分区问题的系统仍能对外提供服务。
场景举例
还是一样的场景：现在有一个主从架构的数据库，我们的应用程序要向主数据库写入数据，同时应用程序同时会向从数据库读取数据。
如果此时要保持分区容错性要求指的是： ·
- 不管是主数据库还是从数据库，其中一个节点挂掉，都不会影响其他节点继续对外提供服务。
如果此时要保持可用性必须这样做：
- 主数据库同步数据到从数据库过程中，不能锁定从数据库的资源。
- 应用程序向从数据库查询数据的过程中一定要返回数据，即使该数据是旧数据，如果旧数据都没有则返回一个默认数据。
可选组合
在刚才的例子中：
如果要满足一致性，需要在数据向主数据库向从数据同步的过程中加锁，同步成功后再释放锁，同步失败时从数据库会返回错误或超时信息。
如果要满足可用性，那么无论何时查询从数据库都要快速响应结果，不能出现响应错误或超时的情况。
很显然，一致性、可用性是矛盾的，况且如果我们选择放弃分区容错性，此时系统并不会进行分区，也就不用考虑网络不通或节点挂掉的问题，此时的系统也就不是一个标准的分布式系统了，换句话说分布式系统是必须考虑网络分区的。
在CAP理论诞生 12 年之后，CAP之父也在 2012 年重写了之前的论文：
当发生网络分区的时候，如果我们要继续服务，那么强一致性和可用性只能 2 选 1。也就是说当网络分区之后 P 是前提，决定了 P 之后才有 C 和 A 的选择。也就是说分区容错性（Partition tolerance）我们是必须要实现的。
因此CAP可选的组合只有AP、CP。
实际应用
聊了这么多，AP和CP有哪些实际应用呢？
注册中心的选择
注册中心是微服务领域最场景的组件了，它解决了两类核心问题：
-
服务注册：实例将自身服务信息注册到注册中心，这部分信息包括服务的主机IP和服务的Port，以及暴露服务自身状态和访问协议信息等。
-
服务发现：实例请求注册中心所依赖的服务信息，服务实例通过注册中心，获取到注册到其中的服务实例的信息，通过这些信息去请求它们提供的服务。
目前微服务领域主流的注册中心组件有：dubbo的zookeeper，SpringCloud的eureka。
zookeeper保证CP
zookeep保证的是CP，即任何时刻对zookeeper的访问请求能得到一致的数据结果。
但它不能保证每次服务的可用性。在使用zookeeper获取服务列表时，如果zk正在选举或者zk集群中半数以上的机器不可用，那么将无法获取数据。所以说，zookeeper不能保证服务可用性。
eureka保证AP
eureka保证的AP，只要有一台eureka存在，就可以保证整个服务处在可用状态。
但eureka某个服务上的信息并不是最新信息。所以说，eureka不能保证数据一致性。
如何选择
对于服务消费者来说，能消费才是最重要的，就算拿到的数据不是最新的数据，消费者本身也可以进行尝试失败重试。
总比为了追求数据的一致性而获取不到实例信息整个服务不可用要好。
所以，对于服务注册来说，可用性比数据一致性更加的重要，选择AP。
Base理论
上面说到，分布式系统只能满足CP或AP两个特性。
在实际场景中，大部分公司会选择AP，保证可用性和分区容错性，舍弃一致性。
但这里舍弃的是强一致性，即任意时间任意节点的数据都保持一致。经过一段时间后我们还是要保证数据是保持一致的，这就引入了Base理论
内容
BASE是eBay的架构师Dan Pritchett于2008年在ACM上发表的。
BASE 是 Basically Available（基本可用） 、Soft-state（软状态） 和 Eventually Consistent（最终一致性） 三个短语的缩写。
该理论是对CAP理论中的AP的一个扩展，它的核心思想是：
当系统出现故障时,允许部分功能不可用，但要保证核心功能可用；允许数据在一段时间内不一致，但经过一段时间，数据最终要保证一致。
基本可用
基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性，比如响应时间或功能，但要保证系统基本可用。
比如，当电商系统出现故障时：
- 响应时间由原来的0.1s变成了1s，但也依然能响应。
- 商品图片加载错误，但下单依然正常。
软状态
软状态指允许系统中的数据存在中间状态，这些状态不会影响系统的整体可用性，只允许系统的各个节点之间的数据同步出现延时。
在电商系统中的订单"支付中"、"退款中"等状态就是软状态。
最终一致性
最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。
最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。
比如，电商系统中的订单"支付中"、"退款中"等状态就是软状态，经过一段时间后，就会变成"支付成功"、"退款成功"的状态。
总结
- 提出了CAP理论。
- 解读了CAP理论的三大特性。
- 分析了CAP的可选组合方式：只能满足CP或AP。
- 列举出了一种CAP的实际应用场景，即我们如何去选择不同的模型。
- 提出了Base理论：是对CAP理论的AP特性的扩展。
- 解读了Base理论的三大要素。
新的一年祝大家事业有成，在职的能够升职加薪、跳槽的能够拿到满意的offer！
如果读者对这篇文章感兴趣，欢迎点赞、评论、转发。
也欢迎大家关注我的公众号："沐晨聊编程"，回复"1"即可领取2022程序员必读电子书。
