CAP

前言

在学习Zookeeper相关知识的时候，了解到了CAP理论。即在分布式系统中，不可能同时满足以下三种

一致性（C:Consistency）

可用性（A:Available）

分区容错性（P:Partition Tolerance）

这三个基本需求，最多只能同时满足其中的两项，因为P是必须的,因此往往选择就在CP或者AP。
理论简单的阐述就是这些，但是仅仅是知道这些，其实是没有真正去理解CAP理论。

相关术语解释

• 一致性

一致性是指从系统外部读取系统内部的数据时，在一定约束条件下相同，即数据变动在系统内部各节点应该是同步的。根据一致性的强弱程度不同，可以将一致性的分类为如下几种：

强一致性：（strong consistency）。任何时刻，任何用户都能读取到最近一次成功更新的数据。

单调一致性：（monotonic consistency）。任何时刻，任何用户一旦读到某个数据在某次更新后的值，那么就不会再读到比这个值更旧的值。也就是说，可获取的数据顺序必是单调递增的。

会话一致性：（session consistency）。任何用户在某次会话中，一旦读到某个数据在某次更新后的值，那么在本次会话中就不会再读到比这值更旧的值，会话一致性是在单调一致性的基础上进一步放松约束，只保证单个用户单个会话内的单调性，在不同用户或同一用户不同会话间则没有保障。

最终一致性：（eventual consistency）。用户只能读到某次更新后的值，但系统保证数据将最终达到完全一致的状态，只是所需时间不能保障。

弱一致性：（weak consistency）。用户无法在确定时间内读到最新更新的值。
- 可用性

可用性是指系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果。这里的重点是”有限时间内”和”返回结果”。

“有限时间内”是指，对于用户的一个操作请求，系统必须能够在指定的时间内返回对 应的处理结果，如果超过了这个时间范围，那么系统就被认为是不可用的。另外，”有限的时间内”是指系统设计之初就设计好的运行指标，通常不同系统之间有很 大的不同，无论如何，对于用户请求，系统必须存在一个合理的响应时间，否则用户便会对系统感到失望。

“返回结果”是可用性的另一个非常重要的指标，它要求系统在完成对用户请求的处理后，返回一个正常的响应结果。正常的响应结果通常能够明确地反映出对请求的处理结果，即成功或失败，而不是一个让用户感到困惑的返回结果。

• 分区容错性

分区容错性约束了一个分布式系统需要具有如下特性：分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。
P是一定要保证的，如果不能保证P，那么我们直接不能提供服务了，可用性和一致性也就更无法谈起了。

网络分区是指在分布式系统中，不同的节点分布在不同的子网络（机房或异地网络等）中，由于一些特殊的原因导致这些子网络之间出现网络不连通的状况，但各个子网络的内部网络是正常的，从而导致整个系统的网络环境被切分成了若干个孤立的区域。需要注意的是，组成一个分布式系统的每个节点的加入与退出都可以看作是一个特殊的网络分区。（另一种简单解释：
一个分布式系统里面，节点组成的网络本来应该是连通的。然而可能因为一些故障，使得有些节点之间不连通了，整个网络就分成了几块区域。数据就散布在了这些不连通的区域中。这就叫分区。）

补充

造成网络分区的原因：

至于 Network Partition（网络分区） 应当理解为 CAP 理论中讨论的故障模型，这里需要注意 Network Partition 并非节点 Crash（节点 Crash 属于 FLP 的故障模型），更侧重于 “节点双方一时联系不上对方” 的一个状态。造成 Partition 的原因可能是网络不可达，也可能是 GC 的 Stop The World 阻塞太久，也可能是 CPU 彪到一个死循环上。更多的情况参见：https://github.com/aphyr/partitions-post

当你一个数据项只在一个节点中保存，那么分区出现后，和这个节点不连通的部分就访问不到这个数据了。这时分区就是无法容忍的。

提高分区容忍性的办法就是一个数据项复制到多个节点上，那么出现分区之后，这一数据项就可能分布到各个区里。容忍性就提高了。然而，要把数据复制到多个节点，就会带来一致性的问题，就是多个节点上面的数据可能是不一致的。要保证一致，每次写操作就都要等待全部节点写成功，而这等待又会带来可用性的问题。
总的来说就是，数据存在的节点越多(因为出现分区之后，如果数据存在的节点越多，那么这一数据项就越可能分布到各个分区中)，分区容忍性越高，但要复制更新的数据就越多，一致性就越难保证。为了保证一致性，更新所有节点数据所需要的时间就越长，可用性就会降低。

总结
经过以上分析，我们可以知道，其实我们的分布式系统是绝对无可能丢弃P的，也就是说，分布式系统要么是选择AP要么是选择CP。

• AP

放弃一致性（这里说的一致性是强一致性），追求分区容错性和可用性，这是很多分布式系统设计时的选择，例如很多NoSQL系统就是如此
- CP

而选择CP，放弃可用性的，典型的有Zookeeper。任何时刻对ZooKeeper的访问请求能得到一致的数据结果（Zookeeper提供的一致性是弱一致性（单调一致性）,首先数据的复制有如下规则:zookeeper确保对znode树的每一个修改都会被复制到集合体中超过半数的机器上。那么就有可能有节点的数据不是最新的而被客户端访问到。并且会有一个时间点,在集群中是不一致的。也就是Zookeeper只保证最终一致性, 但是实时的一致性可以由客户端调用自己来保证,通过调用sync()方法），同时系统对网络分割具备容错性;但是它不能保证每次服务请求的可用性。ZooKeeper是分布式协调服务，它的 职责是保证数据(注：配置数据，状态数据)在其管辖下的所有服务之间保持同步、一致;所以就不难理解为什么ZooKeeper被设计成CP而不是AP特性的了，如果是AP的，那么将会带来恐怖的后果(注：ZooKeeper就像交叉路口的信号灯一样，你能想象在交通要道突然信号灯失灵的情况吗?)。而且， 作为ZooKeeper的核心实现算法 Zab，就是解决了分布式系统下数据如何在多个服务之间保持同步问题的。

Zookeeper集群不可用的情况：

0.进行leader选举时集群都是不可用。在使用ZooKeeper获取服务列表时，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。所以说，ZooKeeper不能保证服务可用性。
如果 ZooKeeper下所有节点都断开了，或者集群中出现了网络分割的故障(注：由于交换机故障导致交换机底下的子网间不能互访);那么ZooKeeper 会将它们都从自己管理范围中剔除出去，外界就不能访问到这些节点了，即便这些节点本身是“健康”的，可以正常提供服务的;所以导致到达这些节点的服务请求 被丢失了。

1.如果ZooKeeper下所有节点都断开了，或者集群中出现了网络分割的故障(注：由于交换机故障导致交换机底下的子网间不能互访);那么ZooKeeper 会将它们都从自己管理范围中剔除出去，外界就不能访问到这些节点了，即便这些节点本身是“健康”的，可以正常提供服务的;所以导致到达这些节点的服务请求 被丢失了。

最后说一下CA,而不能用于分布式系统的CA，其实就是传统的单机数据库的选择，是不能应用在分布式系统中的。

Base理论

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

1、基本可用

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

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

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

2、软状态

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

3、最终一致性

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

总的来说，BASE理论面向的是大型高可用可扩展的分布式系统，和传统的事物ACID特性是相反的，它完全不同于ACID的强一致性模型，而是通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态。但同时，在实际的分布式场景中，不同业务单元和组件对数据一致性的要求是不同的，因此在具体的分布式系统架构设计过程中，ACID特性和BASE理论往往又会结合在一起。

Zookeeper和Eureka

我们知道有两种常见的分布式服务框架，一种是阿里开源的Dubbo，另一种是SpringCloud，其中服务发现默认使用Eureka实现。
- Dubbo

在SpringCloud流行之前，Dubbo是非常常用的一个分布式服务框架。Dubbo使用Zookeeper来现实服务发现功能，Zookeeper充当服务注册中心。

• SpringCloud

而SpringCloud默认是使用Eureka来实现服务发现功能的。SpringCloud将服务发现做了封装，有多种方式来实现服务发现，默认是Eureka，但同时也支持Zookeeper。

这里我们就会有疑问了，为什么SpringCloud抛弃了Zookeeper，而使用了Netflix开源的Eureka来实现服务发现呢？

前面我们已经说了，ZooKeeper在实现上牺牲了可用性，保证了一致性（单调一致性）和分区容错性。

而在服务发现功能中，当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接down掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性。但是zk会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30 ~ 120s，且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因网络问题使得zk集群失去master节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。也就是说服务发现是更要求可用性的。所以实现了CP并不是非常合适用来做服务发现。

而Eureka作为Zookeeper之后的产品，已经意识到这一点，所以Eureka作为服务发现的一个实现，在设计的时候就更考虑了可用性，保证了AP。
Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)。除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：
1. Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
2. Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可用)
3. 当网络稳定时，当前实例新的注册信息会被同步到其它节点中

在出现网络分区的情况下，Eureka将继续接受新的注册并发布。这可以确保新增服务仍然可以供分区同侧的任意客户端使用。
因此， Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪。

所以，总的来说：Eureka作为单纯的服务注册中心来说要比zookeeper更加“专业”，因为注册服务更重要的是可用性，我们可以接受短期内达不到一致性的状况。

如果一个服务器出现问题，Eureka不需要任何类型的选举，客户端会自动切换并连接到一个新的Eureka服务器。当它恢复时，可以自动加入Eureka节点集群。而且，按照设计，它可以在零停机的情况下处理更广泛的网络分区问题。在出现网络分区的情况下，Eureka将继续接受新的注册并发布。这可以确保新增服务仍然可以供分区同侧的任意客户端使用。

Eureka有一个服务心跳的概念，可以阻止过期数据：如果一个服务长时间没有发送心跳，那么Eureka将从服务注册中将其删除。但在出现网络分区、Eureka在短时间内丢失过多客户端时，它会停用这一机制，进入“自我保护模式”。网络恢复后，它又会自动退出该模式。这样，虽然它保留的数据中可能存在错误，却不会丢失任何有效数据。

Eureka在客户端会有缓存。即使所有Eureka服务器不可用，服务注册信息也不会丢失。缓存在这里是恰当的，因为它只在所有的Eureka服务器都没响应的情况下才会用到。

Eureka就是为服务发现而构建的。它提供了一个客户端库，该库提供了服务心跳、服务健康检查、自动发布及缓存刷新等功能。使用ZooKeeper，这些功能都需要自己实现。

管理简单，很容易添加和删除节点。它还提供了一个清晰简洁的网页，上面列出了所有的服务及其健康状况。

Eureka还提供了REST API，使用户可以将其集成到其它可能的用途和查询机制。
参考文献：
https://www.cnblogs.com/szlbm/p/5588543.html