分布式理论 - 现代架构基石 | 青训营笔记

乌云暮年
260 阅读10分钟

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

前言

这是我将参加青训营期间的收获进行整理和总结，同时便于日后复习和查阅。如果能给各位小伙伴提供些帮助，也是我的荣幸，希望大家可以多多赐教，一起学习和交流。

本篇文章内容：

  • 分布式概述
  • 系统模型
  • 理论基础
  • 分布式事务
  • 共识协议
  • 分布式实践
思维导图.png

分布式概述

什么是分布式

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

  • 分布式优势：

    1. 去中心化
    2. 低成本
    3. 弹性
    4. 资源共享
    5. 可靠性高

  • 分布式挑战：

    1. 普遍的节点故障
    2. 不可靠的网络
    3. 异构的机器与硬件环境
    4. 安全

Why-How-What

使用者视角：

  • Why：

    1. 数据爆炸，对存储和计算有大规模运用的述求
    2. 成本低，构建在廉价服务器之上

  • How：

    1. 分布式框架
    2. 成熟的分布式系统

  • What：

    1. 理清规模，负载，一致性要求等
    2. 明确稳定性要求，制定技术方案

学习者视角：

  • Why：

    1. 后端开发必备技能
    2. 帮助理解后台服务器之间写作的机理

  • How：

    1. 掌握分布式理论
    2. 了解一致性协议

  • What：

    1. 把要点深入展开，针对难点搜索互联网资料
    2. 将所学知识运用于实践

常见的分布式系统

分布式存储

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

分布式数据库

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

分布式计算

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

系统模型

故障模型

  • Byzantine failure：节点可以任意篡改发送给其他节点的数据
  • Authentication detectable byzantine failure（ADB）：Byzantine failure的特例；节点可以篡改数据，但不能伪造其他节点的数据
  • Performance failure：节点未在特定时间段内收到数据，即时间太早或太晚
  • Omission failure：节点收到数据的时间无限晚，即收不到数据
  • Crash failure：在哦，ission failure 的基础上，增加了节点停止响应的假设，也即持续性地omission failure
  • Fail-stop failure：在Crash failure的基础上增加了错误可检测的假设
故障描述可能的类型
磁盘故障如：磁头不寻道、盘片不转、磁介质损伤等，年发生率1-2%Fail-stop
磁盘坏道、坏块磁头划伤引起坏道、或受宇宙射线影响晶体管产生位反转Fail-stop，ADB
服务器主板、板卡故障可能式风扇故障，或灰尘引起的短路，或SCSI/RAID卡造成的死机Crash
网络故障电源故障、背板故障等，网卡位反转、网络流量造成大量丢包等Byzantine，Omission
网络分区网络引起节点形成不同的子集，子集中网络相通，子集间网络不同Performance
内存故障内存出错造成的数据备篡改，分为UE、CE两种ADB
线缆故障服务器光模块频繁up或downPerformance，Omission
内核崩溃内核内部的致命错误，产生的kernel，panicCrash
CPU故障年故障率近1%Omission，Crash
电源故障服务器失去电力支撑Omission
软件故障如：进程crash、内存踩坏、状态不一致、配置错误，软件bug等Byzantine，Crash等

拜占庭将军问题

  • 引入： 两将军问题（Two Generals Proble）：两支军队的将军只能派信使穿越敌方领土互相通信，以此约定进攻时间。该问题希望求解如何在两名将军派出的任何信使都可能被俘虏的情况下，就进攻时间达成共识。
  • 结论： 两将军问题是被证实无解的电脑通信问题，两支军队理论上永远无法达成共识。
  • TCP是两将军问题的一个工程解

共识和一致性

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

意思是指不同客户端A和B看到客户端C写入，因为时机的不同，产生数据读取的偏差，称为最终一致性。

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

意思是指要保证所有客户端看到相同的值，需要多节点进行“协商”，达成共识，称之为线性一致性

  • 一致性和可用性是对矛盾

时间和事件顺序

1978年Leslie Lamport发表《Time, Clocks, and the Ordering of Events in a Distributed System》

  • 定义了计算机系统中的时间和事件顺序，引入happened before和并发的定义，可以以此对分布式系统中的事件进行推导。

    定义“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<Ci b
    2. 如果事件a表示节点Pi发送某条消息，b表示节点Pj接受这条消息，则有Ci a < Cj b

理论基础

CAP理论

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

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

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

ACID理论

ACID理论是针对CA系统而言的，通常在数据库中具有广泛意义。

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

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

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

BASE 理论

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

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

分布式事务

二阶段提交

定义：

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

三个假设：

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

可能出现的情况:

  • 情况1) Coordinator不宕机，Participant宕机。
  • 情况2) Coordinator容机，Participant不宕机。可以起新的协调者，待查询状态后，重复二阶段提交
  • 情况3) Coordinator宕机，Participant容机。

回滚: 在Prepare阶段，如果某个事务参与者反馈失败消息，说明该节点的本地事务执行不成功，必须回滚。

情况3: 无法确认状态，需要数据库管理员的介入，防止数据库进入一个不一致的状态

提交需解决的问题：

  • 性能问题：需要多次网络通信，资源需要等待并锁定
  • 新协调者：如何确定状态选出新协调者
  • Commit阶段网络分区带来的数据不一致：非所有节点都收到Commit请求

三阶段提交

三阶段提交将二阶段提交中的Prepare阶段拆分为：CanCommit和PreCommit机制。

解决了两个问题：

  1. 单点故障问题
  2. 阻塞问题

MVCC

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

Spanner论文里通过True Time API提供一个物理时钟的方式。服务器时钟偏差在1到7ms之间。

S1提交事务时间：s1 = max（15.7 + 7） =15ms

S2提交事务时间：s2 = max（13.12 + 7）= 19ms

共识协议

Quorum NWR模型

Quorum NWR三要素

N：在分布式存储系统中，有多少份备份数据。

W：代表一次成功的更新操作要求至少有w份数据写入成功。

R：代表一次成功的读数据操作要求至少有R份数据成功读取

  • 为了保证强一致性，需要保证 W+R>N
  • Quorum NWR模型将CAP的选择交给用户，是一种简化版的一致性模型

RAFT 协议

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

三种角色

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

四种定义

  • Log (日志): 节点之间同步的信息，以只追加写的方式进行同步，解决了数据被覆盖的问题。
  • Term (任期号) : 单调递增，每个Term内最多只有一个Leader。
  • Committed: 日志被复制到多数派节点，即可认为已经被提交。
  • Applied: 日志被应用到本地状态机: 执行了log中命令，修改了内存状态

Leader选举过程：

  1. 初始全部为Follower

  1. Current Term + 1

  2. 选举自己

  3. 向其它参与者发起RequestVote请求，retry直到

    • 收到多数派请求，成为Leader，并发送心跳
    • 收到其它Leader的请求，转为Follower，更新自己的Term
    • 收到部分，但未达到多数派，选举超时，随机timeout开始下一轮

    两个规则

    • 在一个任期内每个参与者最多投一票( 持久化 )
    • 要成为Leader，必须拿到多数投票

Log Replication过程: 新Leader产生，Leader和Follower不同步，Leader强制覆盖Followers的不同步的日志

  1. Leader收到写请求w

  2. 将w写入本地log

  3. 向其它Follower发起AppendEntries RPC

  4. 等待多数派回复

    • 更新本地状态机，返回给客户端
    • 下一个心跳通知Follower上一个Log已经被 Committed了

  5. Follower也有问题，Leader一直retry

切主：

当Leader出现问题时，就需要进行重新选举。

  1. Leader发现时区Follower的响应，失去Leader身份
  2. 两个Follower之间未收到心跳，重新进行选举，选出新的Leader，此时发生了切主
  3. Leader自杀重启，以Follower的身份加入进来

Stale读：

  • 发生Leader切换，old leader收到了读请求。如果直接响应，可能会有Stale Read

Paxos协议

Paxos算法与PAFT算法区别：

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

Paxos优势：写入并发性能高，所有节点都能写入

Paxos缺点：没有一个节点有完整的最新的数据，恢复流程复杂，需要同步历史记录。

分布式实践

MapReduce

MAp.png Mapper: 将输入分解为多个Job来并行处理。彼此间几乎没有依赖关系。

Shuffler: 将maper结果打乱，防止数据倾斜。

Reducer: 对map阶段的结果进行全局汇总。

容错：

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

分布式 KV

分布式.png

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

容错：

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

弹性：

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

引用

  • 《分布式理论》 - 字节青训营录播课
avatar
文章
阅读
粉丝