分布式理论 | 青训营笔记

我不在的日子你还好吗哦好那没事了
122 阅读8分钟

这是我参与「第五届青训营 」伴学笔记创作活动的第 11 天

一、分布式概述

1.分布式的概念

 分布式系统是计算机程序的集合，这些程序利用跨多个独立计算节点的计算资源来实现共同的目标。可以分为分布式计算、分布式存储、分布式数据库等。

 分布式具有的优势：

  • 去中心化
  • 低成本
  • 弹性
  • 资源共享
  • 高可靠

 分布式面临的挑战：

  • 遍的节点故障
  • 不可靠的网络
  • 异构的机器与硬件环境
  • 安全

2.Why-How-What

image.png

3.常见分布式系统

分布式计算

1.Hadoop：基于 MapReduce 的分布式计算框架 2.spark：在 Hadoop 基础之上使用内存来存储数据 3.YARN：分布式资源调度

分布式存储

1.Google File System (GFS)：google 分布式文件系统
2.Ceph：统一的分布式存储系统
3.Hadoop HDFS：基于 GFS 架构的开源分布式文件系统
4.Zookeeper：高可用的分布式数据管理与系统协调框架

分布式数据库

1.Google Spanner：google 可扩展、全球分布式的数据库
2.TiDB：开源分布式关系型数据库
3.HBase：开源 Nosql 数据库
4.MongoDB：文档数据库

二、系统模型

1.故障模型

image.png

  • Byzantine failure：节点可以任意篡改发送给具他节点的数据
  • Authentication detectable byzantine failure(ADB)：Byzantine failure 的特例，节点可以篡改数据，但不能伪造其他节点的数据
  • Performance failure：节点未在特定时间段内收到数据，即时间太早或太晚
  • Omission failure：节点收到数据的时间无限晚，即收不到数据
  • Crash failure：在 omission failure 的基础上，增加了节点停止响应的假设，也即持续性地 omission failure
  • Fail-stop failure：在 Crash failure 的基础上增加了错误可检测的假设

常见故障及类型

image.png

2.拜占庭将军问题

两将军问题

两支军队的将军只能派信使穿越敌方领土互相通信，以此约定进攻时间。该问题希望求解如何在两名将军派出的任何信使都可能被俘虏的兄下，就进攻时间达成共识 。

image.png

方案一：同时发送 N 个信使，任何一个达到对方军队，都算成功。
方案二：设置超时时间，发送后未在一定时间返回，则加派信使。

共识与消息传递的不同：即使保证了消息传递成功，也不能保证达成共识。 结论是，两将军问题是被证实无解的电脑通信问题，两支军队理论上永远无法达成共识。 TCP 三次握手是在两个方向确认包的序列号，增加了超时重试，是两将军问题的一个工程解。

三将军问题（一个叛徒...）、四将军问题（一个叛徒...）

3.共识与一致性

最终一致性

image.png

客户端 A 读到 x = 0，当客户 C 正在写入时，客户端 A 和 B 可能读到 0 或者 1，但是当 C 写入完成后 ， A 和 B 最终能读到一致的数据。我们称这样的一致性为 Eventually consistent（最终一致性）

线性一致性

image.png

当客户端 A 读到更新的版本 x = 1 后，及时将消息同步给其他客户端，这样其他客户端立即能获取到 x = 1。我们称这样的一致性为 Linearizability（ 线性一致性 ）

如果要保证“线性”一致性，多个节点间势必需要进行协商，以寻求一致。这样增加了延迟，系统可用性便会受损。

4.时间和事件顺序

如果 a 和 b 是在相同节点上的两个事件，a 在 b 之前发生， 则定义：a -> b
如果事件 a 表示某个节点发送某条消息，b 是另一个节点接受这条消息，则有 a -> b
如果有且 b x> c ， 则有 a x> c 当且仅当 a 与 b 无直接关系时，我们称两个事件为并发的

Lamport 逻辑时钟

对于每一个节点 Pi 我们定义时钟 Ci 为一个函数，它为任意的事件 a 赋值编号为 Ci(a)
如果 a 和 b 是在相同节点 Pi 上的两个事件，a 在 b 之前发生，则有Ci(a)<Ci(b)
如果事件 a 表示节点 Pi 发送某条消息，b 表示节点 Pj 接受这条消息 ， 则有Ci(a)<Cj(b)

image.png

于是我们可以在时空图中加入类似图虚线所示的 "tick line" 在同一节点内的连续两个事件之间 ， 至少要有一条 tick line 利用逻辑时钟，我们可以对整个系统中的事件进行全序排序

三、理论基础

1.CAP 理论

  • C（Consistence）一致性：指数据在多个副本之间能够保持一致的特性（严格的一致性）。
  • A（Availability）可用性：指系统提供的服务必须一直处于可用的状态，每次请求都能够获得非错的响应，但不保证获取的数据为最新数据。
  • P（Network partitiioning）分区容错性：分布式系统在遇到任何网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务，除非整个网络环境都发生故障。

CAP 理论往往运用于数据库领域，同样可以适用于分布式存储方向。

  • CA：放弃分区容错性，加强一致性和可用性，其实就是传统的单机数据库的选择
  • AP：放弃一致性（ 这里说的一致性是强一致性），追求分区容错性和可用性，例如一些注重用户体验的系统
  • CP：放弃可用性，追求一致性和分区容错性，例如与钱财安全相关的系统。

2.ACID 理论

 事务是库系统中非常重要的概念，它是数据库管理系统执行过程中的一个逻辑单元，它能够保证一个事务中的所有操作要么全部执行， 要么全不执行。

 数据库事务拥有四个特性 ACID，即分别是原子性 (Atomicity)、一致性 (Consistency)、隔离性 (lsolation) 和持久性(Durability)

  • 原子性 (A)：原子性是指事务包含的所有操作要么全部成功，要么全部失败回滚。
  • 一致性 (C)：一致性是指事务必须使库从一个一致性状态变换到另一个一致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态。
  • 隔离性 (I)：隔离性是当多个用户并发访问库时，库为每一个用户开启的事务，不能被其他事务的操作所干扰，多个并发事务之间要相互隔离。
  • 持久性 (D)：持久性是指一个事务一旦被提交了，那么对数据库中的的改变就是永久性的，即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作。

3.BASE 理论

 Base 理论是对 CAP 中一致性和可用性权衡的结果，其来源于对大型互联网分布式实践的总结，是基于CAP 定理逐步演化而来的，其核心思想是：

  • Basically Available（基本可用）：假设系统出现了不可预知的故障，但还是能用，相比较正常的系统而言，响应时间上有损失，或功能上有损失
  • Soft state（软状态）：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。
  • Eventually consistent（最终一致性）：系统能够保证在没有其他新的更新操作的情况下，数据最终一定能够达到一致的状态，因此所有客户端对系统的数据访问最终都能够获取到最新的值。

四、分布式事务

1.两阶段提交

是为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种演算法。

三个假设：
1.引入协调者 (Coordinator) 和参与者 (Participants)，互相进行网络通信
2.所有节点都采用预写式日志，且日志被写入后被保持在可靠的存储设备上
3.所有节点不会永久性损坏，即使损坏后仍然可以恢复

image.png

可能出现的情况

1.Coordinator 不宕机，Participant 宕机。需要讲行回滚操作。

2.Coordinator 宕机，Participant 不宕机。可以起新的协调者，待查洵状态后，重复二阶段提交。

3.Coordinator 宕机，Participant 宕机。无去确认状态，需要数据库管理员的介入，防止让数据库进入不一致的状态。

需要注意的问题

1.性能问题：两阶段提交需要多次节点间的网络通信，耗时过大，资源需要进行锁定，徒增资源等待时间。

2.协调者单点故障问题：如果事务协调者节点宕机，需要另起新的协调者，否则参与者处于中间状态无法完成事务。

3.网络分区带来数据不一致：一部分参与者收到了 Commit 消息，另一部分参与者没收到 Commit 消息，会导致了节点之间数据不一致。

2.三阶段提交

将两阶段提交中的 Prepare 阶段，拆成两部分 ：CanCommit 和 PreCommit 机制。

image.png

解决了两个问题：

1.单点故障问题

2.阻塞问题

3.MVCC

image.png

MVCC 是一种并发控制的方法，维持一个数据的多个版本使读写操作没有冲突。所以既不会阻塞写，也不阻塞读。MVCC 为每个修改保存一个版本，和事务的时间戳相关联。可以提高并发性能，解决脏读的问题。

五、共识协议

1.Quorum NWR 算法

image.png

Quorum NWR 三要素

N：在分布式存储系统中，有多少份备份数据
W：代表一次成功的更新操作要求至少有 w 份数据写入成功
R：代表一次成功的读数据操作要求至少有 R 份数据成功读取

为了保证强一致性，需要保证 W+ R > N

Quorum NWR 模型将 CAP 的选择交给用户，是一种简化版的一致性模型。

2.Raft 协议

Raft 协议是一种分布式一致性算法（共识算法），即使出现部分节点故障，网络延时等情况，也不影响各节点，进而提高系统的整体可用性。Raft 是使用较为广泛的分布式协议。一定意义上讲，Raft 也使用了Quorum 机制。

image.png

  • Leader（领导者），通常一个系统中是一主（Leader）多从（Follower）。Leader 负责处理所有的客户端请求，并向 Follower 同步请求日志，当日志同步到大多数节点后，通知 Follower 提交日志。
  • Follower（跟随者），不会发送任何请求。接受并持久化 Leader 同步的日志，在 Leader 告知日志可以提交后，提交日志。当 Leader出现故障时，主动推荐自己为 Candidate。
  • Candidate（备选者），Leader 选举过程中的临时角色。向其他节点发送请求投票信息。 如果获得大多数选票，则晋升为 Leader。

3.Paxos 协议

Paxos 算法与 RAFT 算法区别 ： 1.Multi-Paxos 可以并发修改日志 ， 而 Raft 写日志操作须是连续的 2.Multi-Paxos 可以随机选主，不必是最新最全的节点当选 Leader

Paxos 优势：写入并发性能高，所有节点都能写入 Paxos 劣势：没有一个节点有完整的最新数据，恢复流程复杂，需要同步历史记录

六、分布式实践

1.MapReduce

image.png

mapper：将输入分解为多个 job 来并行处理，彼此间几乎没有依赖关系 Shuffer：将 maper 结果打乱，防止数据倾斜 Reducer：对 map 阶段的结果进行全局汇总

容错 ： 1.Mapper 故障：由中心化节点重新发起调度 ， 新起 Mapper 重跑 job。 2.Reducer 故障：重跑 Mapper ，代价大。

2.分布式KV

image.png

架构

 将海量结构化数据根据 Key 分成不同的 Region，每个 Region 构建一个单机 KV 数据库，Region 之间形成 Raft Groups，做到强一致。

容错

 当 Node 故障时，通过 Raft Learner 模式进行数据修复。

弹性

 当出现局部 Key 热点或数据膨胀时，Region 可以进行 Split 操作，分成两个子 Region，反之收缩时进行 Merge 操作。

比较详细地介绍了分布式的概念，以及学好和用好分布式需要掌握的技术核心要点，对其中的某及技术要点进行了详细的讲解。

avatar
文章
阅读
粉丝