分布式系统中的基本定理以及关联

FLP, Async/Sync, CAP, BASE, ACID and Eventual Consistency

Posted by Emo on April 12, 2022

分布式系统理论

EMO’s Blog

同步与异步的含义

同步系统的条件

  1. 系统中各个节点的时钟误差存在上限。
  2. 存在一个超时机制,超出时间限制的消息传递视为是失败的。
  3. 各个节点处理消息的时间是一定的。

满足以上条件的同步系统可以轻易的判断节点是宕机了还是消息传输丢失了。

什么是异步系统

首先不满足同步条件的异步系统意味着,系统中的各个节点存在较大的时钟差异,而且消息的传输和处理的时间是任意长的,这就导致了我们无法确定一个节点是故障了还是消息传递慢了。

FLP不可能定理

FLP不可能定理:在网络可靠,但允许节点失效(即使只有一个)的最小化异步系统中,不存在一个可以解决一致性问题的确定性共识算法。也就是说哪怕只有一个节点出错,任何共识算法都无法完美解决异步系统中的一致性问题。所以这个原理告诉我们,不要试图去为异步系统设计一个任何场景下都可以达到一致性的共识算法。

知道了什么是异步系统后,我们就很容易理解FLP了,举个例子网络中A,B,C三个节点要投票决定是否更新某个值,1代表同意,0代表不同意,如果A投票1,B投票0,C接到了A和B的投票,但是C自身宕机了,但是因为是在异步系统中,A和B无法判断C是宕机了还是消息传递得太慢了,于是整个系统将一直等待下去,无法做出一致性的决策。

既然异步系统中无法解决一致性问题,那研究共识算法的意义是什么呢?其实FLP不可能定理只是告诉我们你不要去追求完美的一致性解决方案,我们只要牺牲一些代价就可以让异步系统在一定程度上达到一致。如果强一致性在异步系统中不可达,那么我们可以在异步系统中使用约束性较弱的最终一致性。说到底了,我们还是在做一中Trade off (权衡)。

CAP定理

CAP定理是在探讨三种属性值之间的权衡

  • Consistency一致性

这里指的强一致性,即当系统的更新操作完成并返回客户端后,所有的节点在同一时间的数据是完全一致的。

  • Availability可用性

指分布式系统能够在正常相应时间内提供相应的服务。

  • Partition tolerance分区容忍性

分布式系统在遇到某些节点或者分区故障的时候,仍能够对外提供满足一致性和可用性的服务。

CAP定理指出了在以上三种性质里面,一个分布式系统只能满足其中的两个性质。所以我们在设计分布式系统的时候,需要根据不同的应用场景去在三种性质里面做权衡。其实在大多数的大型互联网应用中,Availability和Partition tolerance是不可舍弃的,所以很多时候我们的系统需要舍弃强一致性而退而求其次选择保证最终一致性,而共识算法则是为了实现最终一致性而被提出来的。

BASE理论

既然上面提到到了Eventual Consistency (最终一致性),这里面接着介绍BASE理论。BASE理论是一种设计理念指:

  • Basic Availability基本可用

指分布式系统在面对故障发生的时候,允许损失部分可用性,保证核心功能可用。比如:

  1. 访问时间上的损失。

  2. 部分功能的损失。

  • Soft State软状态

指允许系统中存在中间状态,而该中间状态不会影响系统的整体可用性。比如分布式存储中一般会有多个数据备份节点,允许节点间在同一个时间点存在状态更新延时,就是软状态。而硬状态则是要求在同一时间节点上,多个节点的状态都是一致的。

  • Eventual Consistency最终一致性

指系统中的所有节点在经过一定的时间后,所有的正常节点最终能够达到一致的状态。也就是说对于软状态,是有一定期限的,在经过一定时间后,处于中间状态的节点一定能够到达最终状态的。

ACID原则

ACID是比较出名的描述一致性的原则,通常出现在分布式数据库领域,也可以说ACID原则描述了分布式数据库的需求。ACID具体指一下及格特性:

  • Atomicity原子性

每次操作是原子性的,要么成功,要么不执行

  • Consistency一致性

数据库的状态是一致的,无中间状态

  • Isolation隔离性

各种操作之间互不影响

  • Durability持久性

状态的改变是持久的,不会失效

BASE和ACID的区别

ACID追求的是强一致性,是传统数据库常用的设计理念,而BASE则支持的是大型的分布式系统,通过牺牲强一致性,追求最终一致性来换取一定的可用性。

最终一致性

在实际工程中,最终一致性一般有5种:

  • Causal consistency因果一致性

如果节点A在更新完某个值后,通知了B,那么B之后的操作都是基于更新后的值,而其他节点则不需要。这里A对这个值的操作和B对这个值的后续操作产生了Happen-Before关系。

  • Read your writes读已之所写

节点A更新一个数据后,它自身总是能访问到自身更新过的最新值,而不会看到旧值

  • Session consistency会话一致性

会话一致性将对系统数据的访问过程框定在了一个会话当中:系统能保证在同一个有效的会话中实现 “读己之所写” 的一致性,也就是说,执行更新操作之后,客户端能够在同一个会话中始终读取到该数据项的最新值。

  • Monotonic read consistency单调读一致性

单调读一致性指的是:如果一个节点从系统中读取出一个数据项的某个值后,那么系统对于该节点后续的任何数据访问都不应该返回更旧的值。

  • Monotonic write consistency单调写一致性

单调写一致性指的是:一个系统要能够保证来自同一个节点的写操作被顺序的执行。

最终一致性,在关系型数据库中其实也有用到,比如在关系型数据库的备份中。数据的复制是需要时间的,如果要在复制的过程中提供服务,那么就避免不了中间状态,但是当然数据库备份是会到达最终状态的。


{ % if page.mermaid % } { % endif % }