第五届字节跳动青训营Class8笔记 ｜ 青训营笔记

吴玘华
225 阅读10分钟

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

本节课程主要讲解了分布式理论的相关知识。

1.分布式概述

分布式系统是计算机程序的集合，这些程序利用多个独立计算节点的计算资源来实现共同的目标。

分布式存储：

  • GFS：Google分布式文件系统
  • Ceph：统一的分布式存储系统
  • Hadoop HDFS：基于GFS架构的开源分布式文件存储系统
  • Zookeeper：高可用的分布式数据管理与系统协调框架

分布式数据库：

  • Google Spanner：google可拓展的的全球分布式数据库
  • TiDB：开源分布式关系型数据库
  • HBase：开源Nosql数据库
  • MongoDB：文档数据库

分布式计算：

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

2.故障模型

  • Byzantine failure：节点可以任意篡改发送给其他节点的数据，是最难处理的故障
  • Authentication detectable byzantine failure (ADB)：节点可以篡改数据，但不能伪造其他节点的数据
  • Performance failure：节点未在特定时间段内收到数据，即时间太早或太晚
  • Omission failure：节点收到数据的时间无限晚，即收不到数据
  • Crash failure：节点停止响应，持续性的故障
  • Fail-stop failure：错误可检测，是最容易处理的故障。

拜占庭将军问题

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

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

TCP三次握手是在两个方向确认包的序列号，增加了超时重试，是两将军问题的工程解。

解决拜占庭将军问题的意义：保持通信-->分布式系统实现的核心

3.理论基础

共识和一致性理论

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

graph TD
M(read=0)
A(A机器)
B(B机器)
C(C机器)
D(read=0/1)
E(read=0/1)
F(write=1)
G(read=1)
M --> A
M --> B
M --> C
A --> D
B --> E
C --> F
F --> D
D --> G

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

graph TD
M(read=0)
A(A机器)
B(B机器)
C(C机器)
D(read=0/1)
E(read=0/1)
F(write=1)
G(read=1)
H(read=1)
M --> A
M --> B
M --> C
A --> D
B --> E
C --> F
F --> D
D --> E
D --> G
E --> H

时间和事件顺序

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
  • 如果a->b b->c 则a->c
  • 当且仅当a/->b且b/->a时，我们称两个事件是并发的

Lamport逻辑时钟

  • 如果a和b是在相同节点上的两个事件，a在b之前发生，则Ci<a> 小于 Ci<b>
  • 如果a和b是在不同节点上的两个事件，且a发送某条消息被b接受，则Ci<a> 小于 Cj<b> 在物理数据上后发生的事件，有可能具有先发生的逻辑顺序

CAP理论

CAP分 别代表一致性、可用性、分区容错性。三者无法同时达到

三类CAP系统：

  • CA系统：传统数据库的代表
  • AP系统：放弃强一致性，保证高可用，不少nosql存储系统采用
  • CP系统：放弃可用性，保证数据一致性

在网络发生分区的情况下，必须在可用性和一致性之间做出选择。近似解决方法：把故障节点的负载转移给备用节点负责。

ACID理论

ACID理论是针对CA系统而言的。

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

  • 原子性(A)：事务包含的操作要么全部成功，要么全部失败回滚
  • 一致性(C)：事务执行之前和之后都必须处于一致性的状态，如A数据库存放的值减a，B数据库存放的值加a，事务结束后A、B数据库存放的值值之和不发生改变
  • 隔离性(I)：多个用户并发访问数据库时彼此不相互影响。
  • 持久性(D)：一个事务一旦提交，对数据库中数据的改变是永久性的，即便在数据库系统遇到故障的情况下也不会丢失提交事务。

I、D性质在常用的数据库中不一定能被实现。

BASE理论

Base理论是针对AP系统而言的。

  • Basically Available(基本可用)：假设系统，出现了不可预知的故障，但还是能用
  • Soft state（软状态）：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性
  • Eventually consistent（最终一致性）：数据最终一定能够达到一致的状态

4.分布式事务

两阶段提交

二阶段提交（Two-phase Commit）：为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种演算法。

三个假设：

  • 协调者和参与者进行通信
  • 预写式日志被保持在可靠的存储设备上
  • 所有节点不会永久性损坏，即使损坏后仍然可以恢复
image.png image.png

提交出现的异常：

  • Prepare阶段失败 -> 回滚；
  • 协调者宕机 -> 重新启用新的协调者；
  • 双故障重启 -> 数据库管理员介入

image.png

可能存在的问题：

  • 性能问题：两阶段提交需要多次节点间的通信，耗时过大且资源需要锁定
  • 单点故障问题：协调者宕机时需要新的协调者
  • 网络分区带来的数据不一致：一部分参与者收到了Commit消息，另一部分参与者没有收到，导致了节点之间的数据不一致

对于日志的保存，分布式系统通常会存储到单机本身的可靠持久化存储上。

三阶段提交

将两阶段提交的Prepare阶段拆成CanCommit和PreCommit两个阶段

当CanCommit过程发现Participants无法完成事务时，就不进行PreCommit过程来建立连接

解决了两个问题：1.单点故障问题 2.阻塞问题

同时引入了超时机制，在超时之后，会继续进行事物的提交。

MVCC

MVCC(Multi-Version Concurrency Control)即多版本并发控制。

悲观锁：

image.png

读写的时候进行上锁避免脏读

乐观锁

image.png

不上锁，只有发现访问冲突时才会拒绝访问

MVCC机制为每个修改保存了一个版本，和事物时间戳相关联。可以提高并发性能，解决脏读问题。

image.png

使用物理时钟的方式（服务器时钟的偏差在1-7ms之间）：

S1提交事务时间：s1 = max(15,7+7)=15ms
S2提交事务时间：s2 = max(13,12+7)=19ms

使用时间戳预言机(TSO)，采用中心化授时方式，所有协调者都向中心化节点获取时钟。但是由于每个节点都要和中心节点交互，会产生网络通信的成本。

总体上MVCC都为每一个时间戳提供了一份数据快照，每一个事务都在各自独立的快照内操作，只能够解决读写问题（幻读、脏读等），不能解决写写问题。 希望解决写写问题仍需要引进锁。

5.共识协议

Quorum NWR模型

  • N：在分布式存储系统中，有多少份备份数据
  • W：代表一次成功的更新操作要求至少有w份数据写入成功
  • R： 代表一次成功的读数据操作要求至少有R份数据成功读取
  • 为了保证强一致性，需要保证 W+R>N

证明：N-W表示未被修改的数据，根据抽屉原理，当R<N-W时，必存在读取了未修改数据的情况，不满足强一致性。

在满足W+R>N的前提下，用户可以根据自己需求修改R,W进而实现CAP其中的某两个性质。

RAFT协议

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

服务器的三种角色

  • Leader - 领导者：Leader 负责处理所有的客户端请求，并向Follower同步请求日志，当日志同步到大多数节点上后，通知Follower提交日志
  • Follower - 跟随者：接受并持久化Leader同步的日志，在Leader告知日志可以提交后，提交日志
  • Candidate - 备选者：Leader选举过程中的临时角色。向其他节点发送请求投票信息

RAFT协议的四个定义：

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

image.png

Leader选举过程

  • 初始全部为Follower
  • Current Term + 1
  • 选举自己
  • 向其它参与者发起RequestVote请求，retry直到
    • 收到多数派请求，成为Leader，并发送心跳
    • 收到其它Leader的请求，转为Follower，更新自己的Term
    • 收到部分，但未达到多数派，选举超时，随机timeout开始下一轮

选举成功后的Leader行为

    • 新Leader产生，Leader和Follower不同步，Leader强制覆盖Followers的不同步的日志

  • 切主：当Leader出现问题时，就需要进行重新选举

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

  • Stale读：

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

切主过程的关键问题：老的Leader未失去身份，新的leader已经选出。 为了解决这一情况，规定在切主之后需要等待老leader的runtime走完，切主才会完成。

Paxos协议

Paxos协议也是实现分布式一致性算法的协议

  • Paxos算法与RAFT算法区别：

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

  • 优劣势

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

6.分布式实践

MapReduce

统计全文字数，使用三层进行处理：

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

image.png

分布式KV

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

容错：Node故障时，通过Raft Learner模式进行数据修复

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

总结

本节课程主要讲解了分布式的概念、模型和理论基础，从CAP出发的各个实现方式入手介绍了几种理论和一致性协议，最后用两个例子进一步实体化了分布式的概念。

avatar
文章
阅读
粉丝