分布式基础理论
1.CAP理论
CAP即Consistency
(一致性)、Availability
(可用性)、Partition-tolerance
(分区容错).
在理论计算机科学中,CAP 定理
(CAP theorem)指出对于一个分布式系统来说,当设计读写操作时,只能同时满足以下三点中的两个:
**Consistency一致性:**所有节点在同一时间内访问的数据完全一致。如果做了
主-从机
,如果要保证一致性,那么主从数据同步的过程中就不能对外提供数据访问。**Availability可用性:**当某个节点挂了的时候,系统能够继续作出响应,而不是返回错误或者无响应。一般需要做
主-从机
Partition-tolerance分区容错性:系统的不同服务节点可能存在不同的区域,服务之间通过网络调用实现,当网络不通或者某一个服务挂掉,就会产生分区。分区容错性就是保证系统产生分区的时候,还能正常运行。
当我们的网络产生分区的时候,如果要保证系统继续能提供服务,那么
P
是前提,决定P
之后才有C
和A
的选择。也就是说分区容错性(Partition tolerance)我们是必须要实现的。
所以分布式系统理论上不可能选择 CA 架构,只能选择 CP 或者 AP 架构
❓ 为什么分布式系统不能实现CA架构?
- 当要保证
可用性A
时,系统就需要主-从机
来保证系统的可用性,如果此时还要保证一致性C
,那么主-从机
只有完成同步达到数据一致的效果才能满足一致性C
,因为主-从机
同步期间需要时间,并且同步的时候禁止其它服务的读写,也就不能提供对外服务,那么此时就不能满足可用性A
。所以分布式系统不可能同时满足CA架构
**CP架构:**满足一致性C
和分区容错性P
Consul注册中心:
- 若Leader主节点挂了,那么就会重新选举Leader主节点,选举期间整个consul集群服务不可用
- 服务注册时间较长,需要将服务同步到一半以上节点时才注册成功。
Zookeeper注册中心:
- 每当master节点挂掉·的时候,系统会进行选举,重新选择其它节点作为master。重新选举需要花费时间,每次选举大概需要花30-120秒,而且选举期间,整个集群都是不可用的,于是造成了选举期间服务注册瘫痪的情况。
- 当半数以上节点不可用时,则整个服务不可用。
**AP架构:**满足可用性A
和分区容错性P
Eureka注册中心:
- 集群没有主从的概念,采用的是
对等通信
,节点通过彼此互相注册来提高可用性。只要有一个节点存活即可提供服务。 - 注册服务时间快,当服务注册到任意节点即注册成功,此时会在各节点进行数据的同步。此时客户端获取到的数据可能不是最新的,因为各节点数据同步需要时间。
- 集群没有主从的概念,采用的是
2.BASE理论
BASE 是 Basically Available(基本可用) 、Soft-state(软状态) 和 Eventually Consistent(最终一致性)
BASE 理论的核心思想:
即使无法做到强一致性
,但每个应用都可以根据自身业务特点,采用适当的方式来使系统达到最终一致性
。
也就是牺牲数据的一致性来满足系统的高可用性,系统中一部分数据不可用或者不一致时,仍需要保持系统整体“主要可用”。
BASE 理论本质上是对 CAP 的延伸和补充,更具体地说,是对 CAP 中 AP 方案的一个补充。
AP 方案只是在系统发生分区的时候放弃一致性,而不是永远放弃一致性。在分区故障恢复后,系统应该达到最终一致性。这一点其实就是 BASE 理论延伸的地方。
基本可用:
基本可用是指分布式系统在出现不可预知故障的时候,允许损失部分可用性。但是,这绝不等价于系统不可用。- 什么叫允许损失部分可用性呢?
- 响应时间上的损失: 正常情况下,处理用户请求需要 0.5s 返回结果,但是由于系统出现故障,处理用户请求的时间变为 3 s。
- 系统功能上的损失:正常情况下,用户可以使用系统的全部功能,但是由于系统访问量突然剧增,系统的部分非核心功能无法使用。
- 什么叫允许损失部分可用性呢?
软状态:
软状态指允许系统中的数据存在中间状态(CAP 理论中的数据不一致),并认为该中间状态的存在不会影响系统的整体可用性,即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。最终一致性:
最终一致性强调的是系统中所有的数据副本,在经过一段时间的同步后,最终能够达到一个一致的状态。因此,最终一致性的本质是需要系统保证最终数据能够达到一致,而不需要实时保证系统数据的强一致性。
参考:
https://javaguide.cn/distributed-system/theorem&algorithm&protocol/cap&base-theorem.html#base-理论三要素