这是我参与「第五届青训营 」伴学笔记创作活动的第 16 天
本文主要介绍分布式理论的基本概念,以及系统模型和理论基础。
基本概念
-
什么是分布式?
- 分布式系统:跨多个节点的计算机程序的集合,这些程序利用跨多个独立计算机节点的计算资源来实现共同目标。
-
分布式系统的优势
- 去中心化
- 低成本(廉价服务器集群)
- 弹性(扩容与缩容)
- 资源共享
- 可靠性高(冗余)
-
为什么要用分布式系统
- 数据爆炸,对存储和计算有大规模应用的需求
- 成本低,构建在廉价的服务器上
-
常见的分布式系统
- 分布式存储:GFS(google file system)、Ceph(统一的分布式存储系统)、HDFS(基于gfs架构的开源分布式文件系统)、Zookeeper
- 分布式数据库:Spanner、TiDB、HBase、MangoDB
- 分布式计算:Hadoop、YARN、Spark
系统模型
故障模型
-
六种故障模型,从处理的难易程度分类
- Byzantine failure:节点可以任意篡改发送给其他节点的数据,这是最难处理的情况,一个节点压根就不按照程序逻辑执行,对它的调用会返回给你随意或者混乱的结果。要解决拜占庭式故障需要有同步网络,并且故障节点必须小于1/3或者消息传递过程中不可篡改,通常只有某些特定领域才会考虑这种情况,通过高冗余来消除故障。
- Authentication detectable byzantine failure (ADB):节点可以篡改数据,但不能伪造其他节点的数据
- Performance failure:节点未在特定时间段内收到数据,即时间太早或太晚(这时可以切换节点,不要在一棵树上吊死)(是故障和非故障的叠加态,比omission failure难)
- Omission failure:节点收到数据的时间无限晚,即收不到数据
- Crash failure:节点停止响应,持续性的故障
- Fail-stop failure:错误可检测,是最容易处理的故障
拜占庭将军问题
-
三将军问题:
- 两个“忠将”A和B,一个“叛徒”C,互相传递消息,消息可能丢失,也可能被篡改,当有一个将军是“叛徒”(即出现拜占庭故障)时,整个系统无法达成一致。
- 由于“叛徒”C的存在,将军A和将军B获得不同的信息。这样会存在一种情况:将军A获得2票进攻1票撤退的信息,将军B获得1票进攻2票撤退的信息,产生了不一致
-
四将军问题(解决三将军问题):
-
将军D作为消息分发中枢,约定如果没收到消息则执行撤退,将军D将命令传达后,将军A,B,C再将消息进行同步
-
步骤:
- 如果D为“叛徒”,ABC无论收到任何消息,经过协商,总会达成一致的结果,无论是进攻还是撤退
- D为“忠将”,ABC有2人将D的消息进行正确的传递,同样能保证最终决策符合大多数。
-
进而能够证明,当有3m+1个将军,m个“叛徒”时,可以进行m轮协商,最终达成一致
-
一致性
强一致性
系统中的某个数据被成功更新后,后续任何对该数据的读取操作都将得到更新后的值;强一致性也被称为线性一致性。
最终一致性
当用户从异步从库读取时,如果此异步从库落后,他可能会看到过时的信息。 这种不一致只是一个暂时的状态——如果等待一段时间,从库最终会赶上并与主库保持一致。这称为最终一致性。
最终两个字用得很微妙,因为从写入主库到反映至从库之间的延迟,可能仅仅是几分之一秒,也可能是几个小时。
逻辑时钟
在分布式系统中的不同节点间保持它们的时钟一致是一件不容易的事情。因为每个节点的CPU都有自己的计时器,而不同计时器之间会产生时间偏移,最终导致不同节点上面的时间不一致。这种情况在某些场景下(金融分布式事务)是不能接受的。
为此提出了逻辑时钟的概念,一般情况下我们提到的时间都是指物理时间,但实际上很多应用中,只要所有机器有相同的时间就够了,这个时间不一定要跟实际时间相同。更进一步,如果两个节点之间不进行交互,那么它们的时间甚至都不需要同步。因此问题的关键点在于节点间的交互要在事件的发生顺序上达成一致,而不是对于时间达成一致。
逻辑时钟:对于任意事件a, b:如果a -> b(->表示a先于b发生),那么C(a) < C(b), 反之不然, 因为有可能是并发事件 C1.如果a和b都是进程Pi里的事件,并且a在b之前,那么Ci(a) < Ci(b) C2.如果a是进程Pi里关于某消息的发送事件,b是另一进程Pj里关于该消息的接收事件,那么Ci(a) < Cj(b)
在实际操作中:
- 每个事件对应一个Lamport时间戳,初始值为0
- 如果事件在节点内发生,本地进程中的时间戳加1
- 如果事件属于发送事件,本地进程中的时间戳加1并在消息中带上该时间戳
- 如果事件属于接收事件,本地进程中的时间戳 = Max(本地时间戳,消息中的时间戳) + 1
理论基础
CAP理论
-
CAP的定义,分别代表一致性、可用性、分区容错性。三者无法同时达到
-
CAP诞生了三类系统:
- CA系统:传统数据库的代表
- AP系统:放弃强一致性,保证高可用,不少nosql存储系统采用
- CP系统:放弃可用性,保证数据一致性
-
举例说明两个分布式进程之间同步数据,当出现故障的时候,如何选择不同的CAP系统,以及带来的影响
- CP系统:故障发生时,为了避免读到不一致的数据,可能拒绝访问
- AP系统:故障发生时,为了保证可用性,允许不同进程读到不同的数据
ACID理论
-
ACID理论是针对CA系统而言的,通常在数据库中具有广泛意义
-
事务是数据库系统中非常重要的概念,它是数据库管理系统执行过程中的一个逻辑单元,它能够保证一个事务中的所有操作要么全部执行,要么全都不执行
-
数据库事务拥有四个特性ACID:
原子性(A)。原子性是指事务包含的所有操作要么全部成功,要么全部失败回滚。 一致性(C)。一致性是指事务必须使数据库从一个一致性状态变换到另一个一致性状态,也就是说一个事务执行之前和执行之后都必须处于一致性状态 隔离性(I)。隔离性是当多个用户并发访问数据库时,数据库为每一个用户开启的事务,不能被其他事务的操作所干扰,多个并发事务之间要相互隔离 持久性(D)。持久性是指一个事务一旦被提交了,那么对数据库中的数据的改变就是永久性的,即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作。
BASE理论
-
BASE理论是针对AP系统而言的,其来源于对大型互联网分布式实践的总结
-
Basically Available(基本可用):假设系统,出现了不可预知的故障,但还是能用
-
Soft state(软状态):允许系统中的数据存在中间状态,并认为该状态不影响系统的整体可用性
-
Eventually consistent(最终一致性):数据最终一定能够达到一致的状态