分布式基础理论

分布式系统中，由于节点直接是分散开的，要保证系统能够应对分布式环境中出现的各种问题

CAP理论

在理论计算机科学中的分布式系统领域，CAP理论(CAP theorem)指的是，对于一个分布式系统而言，当设计读写操作时，只能同时满足以下三点中的两个

为什么是三选二呢，CAP之父Eric Brewer于2012年重写了之前的论文，解释了成因:

当发生网络分区时，如果我们要继续提供服务，那么强一致性和可用性只能二选一。即网络分区后，P分区容错性是前提，决定了P之后才有C和A的选择

所有节点访问同一份最新的数据副本

当写操作成功并响应完毕请求后，所有节点在同一时间的数据完全一致

没有出现故障的节点要在合理的时间内返回合理的响应(而不是错误或者超时的响应)

分布式系统出现网络分区的时候，仍然能够对外提供服务

网络分区是指，分布式系统中多个节点间的网络本来是连通的，因为某些故障比如部分节点的网络出现问题，导致某些节点之间不再连通，整个分布式系统被不同网络分成了几块区域，这就叫做网络分区

如今的云原生环境下，注册中心提供了服务发现和注册的功能，它能够管理分布式系统(比如微服务架构)中的服务节点，为服务提供者和消费者提供两者的元数据(包括服务名称、地址信息、其他元数据等)，通过注册中心，消费者可以接收到注册中心推送的服务提供者的实例信息，使得消费者可以向提供者发起调用

常见的可作为注册中心的组件有:

ZooKeeper: 主要是基于Raft的CP架构，任何时刻对ZooKeeper的读请求都能得到一致性结果，但是不能保证每次请求的可用性，比如Raft中选举Leader中有超过半数以上的机器不可用就会导致整个服务不可用
Eureka: Eureka在设计时优先保证可用性，在Eureka中不存在Leader节点，每个节点都是平等的，即使大部分节点挂掉也不会影响正常提供服务，也就是说哪怕只剩一个节点可用就行，只不过一致性得不到保障(数据可能不是最新的)
Nacos: Nacos集群中各个节点的数据一致性可以由两种分布式协议达成，其一是Raft协议，选举Leader进行数据写入，即CP架构；其二是Distro协议，侧重可用性(或最终一致性)的分布式一致性协议，即AP架构。

Nacos注册中心可以同时使用CP+AP模式管理节点

需要被Nacos服务注册中心(Naming服务)管理的服务实例默认以AP模式启动，如果需要设置为CP，就在配置服务实例的启动参数spring.cloud.nacos.discovery.ephemeral=false(默认为true)

设置为CP模式启动的节点，就是持久化节点，Nacos管理持久化节点不会因为其不在运行而主动剔除

BASE理论于2008年由eBay架构师Dan Pritchett在ACM上发表

BASE为三个短语的缩写，主要是对CAP理论中的一致性C和可用性A进行权衡

即使无法做到强一致性，每个应用也可以根据自身业务特点，采取适当方式使分布式系统达到最终一致性

牺牲数据的一致性而满足系统的高可用性，当系统中部分数据不可用或不一致时，仍需保持系统整体”基本可用”

Basically Available 是指分布式系统出现不可预知的故障时，允许损失部分可用性，但这不等价于系统可用，比如:

允许系统中的数据存在中间状态，比如短暂的数据不一致状态(相比CAP理论的强一致性C而言)，并认为该状态并不影响系统的整体可用性，即运行系统在不同节点的数据副本之间进行数据同步的过程存在延时

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

有3种实现最终一致性的具体方式

强一致性: 系统写入了什么，就读出来了什么，按照CAP理论要牺牲可用性
弱一致性: 系统写入数据成功后，不承诺立即可以读到最新写入的值，也不会承诺具体多久之后可以保证读到更新值，只是说会尽量保证某个时刻达到一致性。这段不一致的窗口简称为”不一致性窗口”
最终一致性: 弱一致性的强化版，系统能够保证一段时间后一定能够达到数据一致性状态，仍然不会实时保证分布式系统数据的强一致性