这是我参与「第五届青训营」伴学笔记创作活动的第 15 天
前言
本文笔记主要内容:
- 分布式介绍
- 系统模型
- 分布式理论基础
1 分布式介绍
1.1 分布式系统
定义:分布式系统是计算机程序的集合,这些程序利用跨多个独立计算节点的计算资源来实现共同的目标。
种类:可以分为分布式计算、分布式存储、分布式数据库等。
1.2 使用分布式系统带来的优势
- 去中心化
- 低成本
- 弹性
- 资源共享
- 可靠性高
1.3 使用分布式系统带来的挑战
- 普遍的节点故障
- 不可靠的网络
- 异构的机器与硬件环境
- 安全
-
Why-How-What
- 使用者视角
- 学习者视角:后端开发必备技能
- 使用者视角
-
常见的分布式系统
-
分布式存储
- Google File System (GFS) : google分布式文件系统
- Ceph: 统一的分布式存储系统
- Hadoop HDFS: 基于GFS架构的开源分布式文件系统
- Zookeeper: 高可用的分布式数据管理与系统协调框架
-
分布式数据库
- Google Spanner: google可扩展的、全球分布式的数据库
- TiDB: 开源分布式关系型数据库
- HBase: 开源Nosal数据库
- MongoDB: 文档数据库
-
分布式计算
- Hadoop: 基于MapReduce分布式计算框架
- Spark: 在Hadoop基础之上,使用内存来存储数据
- YARN: 分布式资源调度
-
2 系统模型
2.1 故障模型
-
六种故障模型:
- Byzantine failure:节点可以任意篡改发送给其他节点的数据,是最难处理的故障
- Authentication detectable byzantine failure (ADB):节点可以篡改数据,但不能伪造其他节点的数据
- Performance failure:节点未在特定时间段内收到数据,即时间太早或太晚
- Omission failure:节点收到数据的时间无限晚,即收不到数据
- Crash failure:节点停止响应,持续性的故障
- Fail-stop failure:错误可检测,是最容易处理的故障
-
故障模型举例(截图)
- 磁盘、主板、交换机、网络分区、cpu、内存、线缆、电源等故障详细说明
2.2 拜占庭将军问题
-
两将军问题
-
定义:两支军队的将军只能派信使穿越敌方领土互相通信,以此约定进攻时间。该问题希望求解如何在两名将军派出的任何信使都可能被俘虏的情况下,就进攻时间达成共识
-
结论:两将军问题是被证实无解的电脑通信问题,两支军队理论上永远无法达成共识
-
TCP三次握手是在两个方向确定包的序列号,同时也增加了超时重试,是两将军问题的一个工程解
-
-
三将军问题:
- 两个“忠将”A和B,一个“叛徒”C,互相传递消息,消息可能丢失,也可能被篡改,当有一个将军是“叛徒”(即出现拜占庭故障)时,整个系统无法达成一致。
- 由于“叛徒”C的存在,将军A和将军B获得不同的信息。这样将军A获得2票进攻1票撤退的信息,将军B获得1票进攻2票撤退的信息,产生了不一致。
-
四将军问题:
-
将军D作为消息分发中枢,约定如果没收到消息则执行撤退
-
四将军下的情况:
- 如果D为“叛徒”,ABC无论收到任何消息,总能达成一致
- D为“忠将”,ABC有2人将D的消息进行正确的传递,同样能保证最终决策符合大多数。
-
进而可以推导出这样的结论:当有3m+1个将军,m个“叛徒”时,可以进行m轮协商,最终达成一致
-
2.3 共识和一致性
- 客户端A读到x=0,当客户端C正在写入时客户端A和B可能读到0或者1。但是当C写入完成后,A和B最终能读到一致的数据我们称这样的一致性为Eventuallyconsistent (最终一致性),会出现“读请求和写请求并发时可能读到旧值”的情况。
- 当客户端A读到更新的版本x=1后,及时将消息同步给其他客户端,这样其他客户端立即能获取到x=1。我们称这样的一致性为Linearizability (线性一致性),会出现“一旦某个读获取到新值,所有客户端都必须返回新值”的情况.
- 如果要保证“线性”一致性,多个节点间势必需要进行协商,以寻求一致。这样增加了延迟,系统可用性便会受损,因此,我们知道,系统可用性和一致性是矛盾的。
2.4 时间和事件顺序
-
概念来由:1978年Leslie Lamport发表《Time, Clocks, and the Ordering of Events in a Distributed System》
-
定义了计算机系统中的时间和事件顺序,引入happened before的关系,有“->”,满足以下条件:
- 如果 a 和 b 是在相同节点上的两个事件,a 在 b 之前发生,则定义:a->b
- 如果事件 a 表示某个节点发送某条消息,b 是另一个节点接受这条消息则有 a->b
- 如果有 a->b 且 b->c,则有 a->c,当且仅当 a-/->b 且 b-/->a 时,我们称两个事件为并发的(concurrent)。
-
根据上述推导,创造了Lamport逻辑时钟的概念
//Lamport逻辑时钟 对于每一个节点 Pi 我们定义时钟 Ci 为一个函数,它为任意的事件 a 赋值编号为 Ci(a) 1.如果 a 和 b 是在相同节点 Pi 上的两个事件,a 在 b 之前发生,则有Ci(a)<Cib) 2.如果事件 a 表示节点 Pi 发送某条消息,b 表示节点 P 接受这条消息,则有Ci(a)<Cj(b)- 于是我们可以在时空图中加入类似右图虚线所示的"tick line"
- 在同一节点内的连续两个事件之间,至少要有一条 tick line
- 利用逻辑时钟,我们可以对整个系统中的事件进行全序排序
3 分布式理论基础(重要)
3.1 CAP理论
-
CAP的每个字母分别代表一致性、可用性、分区容错性- C (Consistence):数据在多个副本之间能够保持一致的特性 (严格的一致性)
- A (Availability):系统提供的服务必须一直处于可用的状态,每次请求都能获取到非错的响应一一但是不保证获取的数据为最新数据
- P (Network partitioning):分布式系统在遇到任何网络分区故障的时候,仍然能够对外提供满足一致性和可用性的服务,除非整个网络环境都发生了故障。
-
运用于数据库领域,但同样适用于分布式存储方向,有下列三种系统
- CA系统:放弃分区容错性,加强一致性和可用性,传统单机数据库的代表
- AP系统:放弃强一致性,注重用户体验的系统,追求可用性与分区容错性
- CP系统:放弃可用性,追求一致性与分区容错性,例如钱财安全相关的系统
-
课程举例说明两个分布式进程之间同步数据的故障情况:
- CP系统:故障发生时,为了避免读到不一致的数据,可能拒绝访问
- AP系统:故障发生时,为了保证可用性,允许不同进程读到不同的数据
-
针对故障场景,可以通过故障转移的方式,做一个相对较优的解决方式:
- 在网络发生分区的情况下,我们必须在可用性和一致性之间做出选择。
- 方法:把故障节点的负载转移给备用节点负责,允许一个进程作为Master,其他进程作为Backup,当故障时将请求转移给Backup进行处理
3.2 ACID理论
- 事务是数据库系统中非常重要的概念,它是数据库管理系统执行过程中的一个逻辑单元,它能够保证一个事务中的所有操作要么全部执行,要么全都不执行
- 数据库事务拥有四个特性ACID:原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)和持久性(Durability)
- 原子性:事务包含的所有操作要么全部成功,要么全部失败回滚。
- 一致性:事务必须使数据库从一个一致性状态变换到另一个一致性状态,也就是说一个事务执行之前和执行之后都必须处于一致性状态。
- 隔离性:当多个用户并发访问数据库时,数据库为每一个用户开启的事务,不能被其他事务的操作所干扰,多个并发事务之间要相互隔离
- 持久性:一个事务一旦被提交了,那么对数据库中的数据的改变就是永久性的,即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作。
PS: ACID理论是针对CA系统而言的,在数据库领域有重要意义
3.3 BASE理论
Base 理论是对CAP中一致性和可用性权衡的结果,针对AP系统而言的,来源于对大型互联网分布式实践的总结,是基于CAP定理逐步演化而来的。有三大核心思想:
- Basically Available(基本可用):假设系统,出现了不可预知的故障,但还是能用,相比较正常的系统而言: 响应时间上的损失或功能上的损失
- Soft state(软状态):允许系统中的数据存在中间状态,并认为该状态不影响系统的整体可用性,即允许系统在多个不同节点的数据副本存在数据延时。
- Eventually consistent(最终一致性):系统能够保证在没有其他新的更新操作的情况下,数据最终一定能够达到一致的状态因此所有客户端对系统的数据访问最终都能够获取到最新的值
心得
今天课程进行分布式系统进行介绍和模型的说明,更详细学习了分布式基础知识(CAP理论、ACID理论、BASE理论),收获颇多,尤其对各个理论的产生与说明,以及它们的关联,老师都讲得清清楚楚,不过对于我来说还需要时间去消化,尤其是CAP理论的例子,需要反复琢磨理解。今天课程的内容较多,先完成对今天的部分知识的笔记和总结,明天再消化分布式事务、共识协议、分布式实践的内容,互勉加油,努力学习后端知识!
引用
ppt:分布式理论 - 现代架构基石.pptx - 飞书云文档 (feishu.cn)