深入理解分布式、微服务中CAP定律和BASE理论

一、背景

随着互联网的蔓延，各种传统项目(单体应用)已经不能够满足当前各种复杂的场景需求，都逐渐向分布式服务、微服务做转换，如今分布式、微服务已经普遍存在，大型网站几乎都是分布式、微服务架构的，分布式和微服务架构就显得尤为重要了。分布式和微服务系统的最大难点，就是各个节点的状态如何保持同步，这也是理解分布式、微服务的起点，设计和部署分布式系统时，所有分布式及微服务系统都需遵循CAP定律和BASE理论，下面我们就来探讨下经典的CAP定律和BASE理论以及现实项目场景中常见的CAP定律组合。

二、CAP定律

这个定理的内容是指的是在一个分布式系统中、Consistency（一致性）、Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼，CAP即三个单词的缩写，在分布式及微服务系统中统称为CAP理论 。

1. Consistency（一致性）

在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）
白话理解：
在设计设计或者部署一个分布式系统时，假设存在两个Redis库，分别是Redis主和Redis从库，用户在往数据库插入一笔记录 ，那么会在保存到数据库的同时也会实时的插入到Redis缓存中，并且主从库保持同步，如果这时候向数据库查询，在网络延迟的情况下，在同一时刻，Redis主和Redis从库查询到的数据应该是一致性的，每个节点的数据是相同的，不能允许有脏读。

2. Availability（可用性）

在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）
白话理解：
假设在分布式部署中，有以下集群部署节点，如果Tomcat1出现故障，Nginx会自动做故障转移，自动将请求转移到Tomcat2和Tomcat3，Nginx故障转移可帮助我们实现集群环境的可用性

3. Partition tolerance（分区容错性）

以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。
白话理解：
分区容错性是指系统能够容忍节点之间的网络通信的故障，假设我们有一台Tomcat服务器，部署在全国各地，像浙江节点、上海节点、武汉节点，但是可能出现其中某个节点由于网络故障不能使用，无法进行通讯；一般来说，现实中分区容错是无法避免的，因此可以认为 CAP的 P总是成立。CAP定理告诉我们，剩下的 C 和 A 无法同时做到。

4. CAP定律组合

在分布式、微服务系统中，CAP定律三者无法同时兼顾，其中可以容忍网络之间出现的通讯故障，只能CP和AP二选一。

• CP： 当网络出现故障之后，只能保证数据一致性，但是不能保证可用性(Zookeeper），意味着服务不能用；
• AP： 当网络出现故障之后，不能保证数据一致性， 但是能保证可用性(比如Eureka)，意味着可允许短暂的数据不一致性，但最终需达到一致，其他节点可正常提供服务；

三、BASE理论

BASE是Basically Available（基本可用）、Soft state（软状态）和 Eventually consistent（最终一致性）三个短语的缩写。BASE理论是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结， 是基于CAP定理逐步演化而来的。BASE理论的核心思想是： 即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。

注意： 在分布式系统中，不可能存在强一致性问题

1、基本可用

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

（1）响应时间上的损失。正常情况下，一个在线搜索引擎需要在0.5秒之内返回给用户相应的查询结果，但由于出现故障，查询结果的响应时间增加了1~2秒

（2）系统功能上的损失：正常情况下，在一个电子商务网站上进行购物的时候，消费者几乎能够顺利完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面

2、软状态

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

3、最终一致性

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

四、一致性问题

1. 一致性基本思想

在分布式系统中，无法保证强一致性，因为短暂的数据存在延迟是允许的，但是最终数据一定要保持数据一致性。

2. 强制一致性

第一步在修改数据库的name = 李四的时候，第二步读取的name内容；如果要一定读取到name为李四而不是张三的话，那么数据库之间的通讯要非常迅速或者说第二步需要等待第一步更新同步完成之后再去做查询，这种流程我们称为强一致性，但是在分布式系统中这种强一致性是不可能存在的，各个服务之间在网络通讯的情况下，肯定存在延迟或者故障的。

3. 弱一致性

允许数据库之间同步数据存在短暂的延迟，第二步可以读取name内容为张三而不是必须为李四；这种例子我们可以称作为弱一致性；

4. 最终一致性

允许第二步读取name为张三，中间允许数据库存在短暂延迟、但是最终的读取数据结果必须为李四，所以这种例子我们称作为最终一致性；

五、Eureka与Zookeeper区别

1. CAP定律

• C(一致性) 各个节点数据必须统一保持一致；
• A(可用性) 保证服务的高可用 必须返回响应结果
• P(分区容错) 网络分区可能会造成脑裂问题，部分server与集群其他节点失去联系 无法组成一个群体；
  不能三者兼顾 只能实现取舍 CP、AP、CA

2. Eureka与Zookeeper区别；

• 相同点：
  • 都是可以实现服务注册与发现 ；
• 不同点：
  • SpringCloud中采用Eureka作为注册中心；
  • Dubbo中采用Zookeeper作为注册中心；
  • Zookeeper如果有过半数服务宕机了，可能存在无法使用，但保证了一致性(保证CP)；
  • Eureka如果有服务宕机了，保证其他服务可用即可，保证了可用性(保证AP)；

3. 所有服务注册中心相同原理

我可以允许暂短读取到原来的老数据服务注册地址信息，但是必须保证注册中心可用；

4. Zookeeper作为注册中心特征

保证CP（一致性），当我们在集群集群环境中，如果某个节点发生了宕机的情况，需要重新实现选举策略，选举的过程中需要一些时间，其底层采用zab协议保持集群之后的每个节点数据一致性；可能导致Zookeeper不能正常使用，如果Zookeeper选举的剩余节点没有过于半数导致整个Zookeeper注册无法使用，但是每个节点数据的一致性的问题；

5. Eureka作为注册中心特征：

保证AP（可用性），Eureka采用去中心化思想，如果使用Eureka实现集群，它的每个节点都是相等的；没有主从概念 ，采用相互注册原理 ，如果客户端访问的eureka宕机之后会自动切换其他eureka节点；只要能够有一台eureka服务正常使用，整个服务注册中心就使用；

六、Nacos与Eureka区别

1. 从CAP模式上的区别

• eureka采用AP设计理念实现注册中心。
• nacos默认采用AP模式，从1.0版本以后采用AP+CP混合模式实现注册中心，既支持AP也支持CP

2. 从实现高可用集群的协议区别

• Eureka实现高可用是采用去中心化思想，没有主从之分，也就是没有Leader角色，每个节点都是相等，采用相互注册原理。
• Nacos从1.0版本支持CP和AP混合模式集群，默认是采用Ap保证服务可用性; CP的形式底层集群采用raft协议保证数据的一致性的问题，选举Leader角色。