分布式基础理论之CAP 和BASE

前言

本文聊聊 CAP 定理和 BASE 理论。

CAP 定理

C:一致性(Consistency)

  • 数据的强一致性。希望分布式系统只读到最新写入的数据

A:可用性(Availability)

  • 分布式系统能提供服务就行,数据的不一致可以忍受

P:分区容错性(Partition tolerance)

  • 分布式系统下,多个节点之间无法通信的情况下,节点被隔离,产生了网络分区,整个系统仍然是可以工作的。

CAP定理: 在网络节点之间无法通信的情况下, 和数据复制相关的功能, 要么选择可用性(A) , 要么选择一致性(C), 不能同时选择两者。

分布式系统下,如果产生了网络分区(P),此时P已经客观存在。那么我们需要在可用性A和强一致性C中做出取舍。分区A和分区B,不能通信,一方的数据无法同步给另一方,我们是选择不忍受数据的强一致性,不提供服务(保C不留A)。还是忍受分区A和分区B 的数据不一致(报A不留C),给客户端提供可用服务呢。

那么如果没有网络分区的情况下,节点之间通信正常。此时P是不存在的。那么我们是可以满足AC的。需要注意的是,不存在网络分区P,我们在分布式系统中满足AC也是对架构有很高要求的。

换言之就是分布式系统下C、A、P不可能同时满足。最多满足两者。

在互联网项目中根据需求进行取舍。通常选择AP 保证最终一致性。但如果银行可能需要强一致性做保障。

BASE 理论

BASE理论是CAP理论不能同时满足的折中理论。看它是四个字母,其实讲的是三个属性, 而每个属性其实包含着两个单词。

Basically Available: 基本可用

我们试想一个两个人对同一个账户进行取钱的操作,这个两个操作被分配到两个机器上。此时这两个机器产生了网络分区,那么如果我们提供可用性的话,两个人都从账户上取出了钱,但如果他们取出的钱超出了账户余额,那么对于银行来说,取钱是一件很麻烦的事情。

上面说到银行通常选择强一致性,那么就放弃可用性了吗。我们可以提供一个基本可用的折中方案,让集群中拥有较多机器的部分继续提供服务,另一部分不接受任何请求,等待网络分区结束后再恢复服务。他们没有利用整个集群的能力,只是利用了其中的一部分。也就是说让一个人能够取出钱来?

为什么说是基本可用(Basically Available)而不是说部分可用(Partially Available)呢?

因为在部分可用的时候,系统不一定是可用的。

Soft State:软状态

软状态在网络分区发生的时候,允许集群中的不同部分都能被访问到。并且,这个时候他们对集群中不同节点的不同操作可能会有不同的状态。如果业务上认为这种不一致是能够容忍的,那么软状态的存在就没有问题,比如说文章的点击数,不是很重要的业务,对用户阻碍也不大。

Eventually Consistency: 最终一致性

如果在网络分区结束后,集群能够自动解决两个部分之间的冲突,让集群达成一致性的状态,那么我们可以说这个集群实现了最终一致性。

这个时候集群没有了网络分区P,重回了拥有CA属性的状态。

补充问题

单机没有P 那么就有CA吗

单节点的系统没有网络分区,那么就自带CA属性吗?

C一致性是客观存在的,如果不考虑并发造成的数据不一致。但是单节点是不拥有可用性A 的,想想为何后来的架构发展为何会走向分布式 微服务。单节点通常在访问量增大时,处理能力有限。可用性就很差了,宕机后,系统直接是不可用的。不能规避单点故障。

不存在网络分区P的情况下 如何更好的满足CA呢

前面讲到在没有网络分区P的情况下,我们想要满足CA也是需要一定难度的。

主动-被动复制模式

在不同的位置持有副本,但是只允许对于其中一个位置的状态做修改。

这种模式可以理解为一主多从,主节点负责写,从节点负责读。由主节点将写操作同步给从节点。

  • 集群的成员能够发现和枚举所有副本位置
  • 集群保证始终只有一个主节点在允许
  • 主节点接收写处理,将处理进行广播,并且当所有从节点应答成功后,主节点应答客户端成功
  • 多个备份节点,防止数据丢失

此时如果主节点如果挂了,系统能够能够进行故障处理。

  • 如何保证只有一个主节点?
  • 主节点挂了,如何进行切换(故障自动转移)?
  • 怎样才算是负责成功?
  • 从节点 状态滞后怎么办?
  • 发生分区时如何选C和A?

当主动副本接收到更新请求的时候,它会接受请求,并将其广播到被动副本,并在得到肯定回复的时候,应答客户端。那么,我们要考虑的是,要等到多少个被动副本应答之后,才算复制成功了?要求更多的副本应答,能显著减少数据丢失的可能性,并保障系统的一致性;要求更少的副本应答,能显著减少副本响应缓慢带来的延迟,提高可用性。但是这个数目是确定的,假设其为 N。也就是说,必须要有 N 个副本应答之后,系统才能接受更新成功。否则主动副本会一直等待集群确认,直到超时。

基本可用也就是要表达这个意思:你的可用分区必须至少要有 N 个副本,才能达成对更新的确认。少于 N 个的话,要么想办法减少 N 的值,要么想办法添加新的副本进去。否则,系统连基本可用都无法保障。

主动-被动复制模式的优点在于,当系统运行良好的时候,这种模式的性能会非常好,因为主动副本不需要执行协调任务;所有的读请求都能在不需要额外通信的情况下得到响应;写入请求只需要多数副本确认即可。

而当系统有失败发生的时候,它将有两种不同情形的性能退化。如果被动副本节点失败重启,那么为了跟上最新的状态,它将占用较多的流量来请求大部分更新;如果主动副本节点失败的话,就会有一段时间内没有任何主动副本在运行。此时集群需要花费时间来确认节点已经失效,并且需要在集群中选出新的主动副本,来协调整体的更新。而在这段时间内,系统的表现是不可用的。

多主复制模式

在不同的位置上保持服务的多个副本,每处都可以接受修改,并将所有修改在各个副本之间传播。

可以通过多种方法来实现多主复制模式,他们之间的不同则在于发生网络分区的时候,如何处理更新请求。我们这里主要说一下基于共识的复制。

基于共识的复制是最具一致性的方式,它通过对每个更新都确立共识的方式实现,代价则是网络分区的时候,不能处理任何请求(保有 CP)。

多主复制模式意味着每一个副本都能接收到更新请求,并能在集群内部对该请求提起共识请求。任何流入的更新都以编号的形式写入到一个虚拟的账本(复制日志)中,并且每个节点都要对哪个更新在哪一行取得共识,这样每个副本都能根据这个账本达到当前状态。这样就在集群内部实现了一致性。而这里的共识操作,我们可以使用 Raft 算法来达成。

多主复制模式其实还有如下两种方案:

  • 具有冲突检测与处理方案的复制: 在网络分区的时候,接受可能会发生冲突的更新请求。而这些冲突可以在分区结束之后解决。只是可能会要丢弃部分已经被确认过的更新。

  • 限定数据模型,使用无冲突的可复制数据结构。这样的并发更新天生就是无冲突的,只需要在集群中进行复制即可。

另外还有主动-主动复制模式,它的策略是在不同的地方持有服务的多份副本,并在所有副本上执行所有的修改操作。这样,每个副本都会执行相同的更新操作,它们之间的状态是保持一致的。只是我们需要一个协调者来负责将更新请求发送给每一个副本。

我们可以发现保证系统高可用一个重要因素就是冗余 避免单点故障。并且能完成故障自动转移。

References

  • 公众号:写Scala的老王
上一篇:记一次排错,windows日志 模块 DLL C:\Windows\system32\inetsrv\aspnetcore.dll 未能加载。返回的数据为错误信息。


下一篇:CyclicBarrier