CAP&BASE理论

CAP

简介

CAP也就是Consistency(一致性)、Availability(可用性)、Partition Tolerance(分区容错性) 这三个单词首字母组合

java.drawio.png

在理论计算机科学中,CAP定理 指出对于一个分布式系统来说,当设计读写操作时,只能同时满足以下三点中的两个:

  • 一致性:所有节点访问同一份最新的数据副本
  • 可用性:非故障的节点在合理的时间内返回合理的响应(不是错误或者超时的响应)
  • 分区容错性:分布式系统出现网络分区的时候,仍然能够对外提供服务

什么是网络分区?

分布式系统中,多个节点之前的网络本来是连通的,但是因为某些故障(比如部分节点网络出了问题)某些节点之间不连通了,整个网络就分成了几块区域,这就叫网络分区。

当发生网络分区时,说明多个节点之间的数据不同步

不是所谓的"3选2"

在CAP的3个特性中,我们并不能满足其中任意的2个特性,例如我们不能选择CA架构,只能选择CP或者AP架构。比如zookeeper是CP架构,Cassandra、Eureka就是AP架构,Nacos不仅支持CP架构也支持AP架构。

为什么不能选择CA架构?

因为如果当系统出现分区,系统中某个节点在进行写操作,为了保证C(一致性),就必须要禁止其他节点的读写操作,这就和A(可用性)发生冲突了。

如果为了保证A,其他节点的读写操作正常的话,就会造成数据在多个节点之间的不一致,那就和C冲突了。

为什么必须保证P(分区容错性)?

因为网络是不可靠的,经常会出现网络分区,如果出现网络分区时,整个服务就不可用,那么分布式应用就无法实现高可用,也就失去了意义。

选择CP还是AP?

选择CP还是AP的关键在于当前的业务场景,没有定论,比如对于需要确保强一致性的场景如银行业务,一般会选择CP。

CAP实际应用案例

以注册中心来探讨一下CAP的实际应用

常见的可以作为注册中心的组件有:ZooKeeper、Eureka、Nacos等

  1. ZooKeeper保证的是CP。任何时刻对ZooKeeper的读请求都能得到一致性的结果,但是,ZooKeeper不保证每次请求的可用性比如在Leader选举过程中或者半数以上的机器不可用的时候服务就是不可用的。
  2. Eureka保证的则是AP。Eureka在设计的时候就是优先保证A(可用性)。在Eureka中不存在什么leader节点,每个节点都是一样的、平等。因此Eureka不会像ZooKeeper那样出现选择过程或者半数机器不可用的时候服务就不可用的情况。Eureka保证即使大部分节点挂掉也不会影响正常提供服务,只要有一个节点是可用的就行了。只不过这个节点上的数据可能并不是最新的。
  3. Nacos不仅支持CP也支持AP。

BASE

Paxos算法

Raft算法