分布式理论 ｜ 青训营笔记

可是我不会啊
156 阅读8分钟

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

一、本堂课重点内容：

  1. 故障模型
  2. 拜占庭将军问题
  3. CAP
  4. ACID
  5. 两阶段提交
  6. RAFT协议

二、详细知识点介绍：

常见分布式系统

分布式存储：

1. Google File System(GFS)
2. Ceph
3. Hadoop HDFS
4. Zookeeper

分布式数据库

1. Google Spanner
2. TiDB
3. HBase
4. MongoDB

分布式计算

1. Hadoop
2. Spark
3. YARN

故障模型

  • Byzantine failure：节点可以任意篡改发送给其他节点的数据 -Authentication detecttable byzantine failure(ADB)：Byzantine failure特例，节点可以篡改数据，但不能伪造其他节点的数据
  • Performance failure：节点未在特定时间段内收到数据，即时间太早或太晚
  • Omission failure：节点收到数据的时间无限晚，即收不到数据
  • Crash failure：在omission failure的基础上，增加了节点停止响应的假设，也即持续性地omission failure
  • Fail-stop failure：在Crash failure的基础上增加了错误可检测的假设
故障可能类型
磁盘故障Fail-stop
磁盘坏道\坏块Fail-stop,ABD
服务器主板、板卡故障Crash
网络故障Byzantine，Omission
网络分区Performance
内存故障ADB
线缆故障Performance，Omission
内核崩溃Crash
CPU故障Omission、Crash
电源故障Omission
软件故障Byzantine、Crash等

拜占庭将军问题

  • 两将军问题：永远无法达成共识
    方案一：同时发送N个信使，任何一个达到敌方军队，都算成功。
    方案二：设置超时时间，发送后未在一定时间返回，则加派信使。

TCP 三次握手是两将军问题工程解

  • 三将军问题
    • 当有一个将军是”叛徒“，整个系统无法达成一致。
  • 四将军问题
    • 如果消息分发中枢D为”叛徒 “，ABC总能达成一致
    • D为”忠将“，最终决策符合大多数
    • 当有3m+1个将军，m个”叛徒“，可以进行m轮协商，最终达成一致。

共识和一致性

不同客户端A和B看到客户端C写入，因为时机不同，产生数据读取的偏差。引导出最终一致性的详细说明 image.png 要保证所有客户端看到相同的值，需要多节点进行”协商“，达成共识，来保证线性一致性 image.png 一致性和可用性是矛盾的

时间和事件顺序

拜占庭将军问题提出者Leslie Lamport于1978年发表《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 ⇏ a时，这两个事件为并发的
  • 根据上述推导，创造了Lamport逻辑时钟的概念，这个概念在分布式理论中具有革命性的意义，帮助我们在一系列分布式事件当中梳理出逻辑的先后关系。利用逻辑时钟，我们可以对整个系统中的事件进行全序排序
    • 如果a 和 b 是在相同节点 Pi 上的两个事件，a 在 b 之前发生，则有Ci(a) < Ci(b)
    • 如果事件 a 表示节点 Pi 发送某条消息，b 表示节点 Pj接受这条消息，则有Ci(a) < Cj(b)

CAP理论

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

  • CAP诞生了三类系统：

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

  • 举例说明两个分布式进程之间同步数据，当出现故障的时候，如何选择不同的CAP系统，以及带来的影响

    • CP系统：故障发生时，为了避免读到不一致的数据，可能拒绝访问
    • AP系统：故障发生时，为了保证可用性，允许不同进程读到不同的数据

  • 针对故障场景，可以通过故障转移的方式，做一个相对较优的解决方式：

    • 允许一个进程作为Master，其他进程作为Backup，当故障时将请求转移给Backup进行处理

image.png

ACID理论

  • ACID理论是针对CA系统而言的，通常在数据库中具有广泛意义
  • 事务是数据库系统中非常重要的概念，它是数据库管理系统执行过程中的一个逻辑单元，它能够保证一个事务中的所有操作要么全部执行，要么全都不执行
  • 数据库事务拥有四个特性ACID：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability）

image.png

AC是要一定要保证的，Oracle数据库保证不了I，MySQL保证不了D

分布式事务

二阶段提交

  • 定义：

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

  • 三个假设：

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

  • 正常流程：Prepare阶段和Commit阶段

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

  • 两阶段提交需解决的问题：

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

image.png

三阶段提交

  • 针对两阶段提交的补充，将两阶段提交中的Prepare阶段，拆成两部分：CanCommit和PreCommit机制
  • CanCommit阶段：询问是否可以执行；PreCommit阶段：重新确认是否可以执行
  • DoCommit阶段：向所有人提交事务

image.png

MVCC

  • MVCC：多版本并发控制的方法。维持一个数据的多个版本使读写操作没有冲突。所以既不会阻塞写，也不阻塞读。提高并发性能的同时也解决了脏读的问题。

  • 悲观锁和乐观锁

    • 悲观锁：操作数据时直接把数据锁住，直到操作完成后才会释放锁；上锁期间其他人不能修改数据
    • 乐观锁：不会上锁，只是在执行更新时判断别人是否修改数据，只有冲突时才放弃操作

image.png

  • 版本的选取：使用物理时钟或逻辑时钟

    • 物理时钟：提供TrueTime API，有Master节点维持一个绝对时间，保证各个服务器之间时钟误差控制在ϵ内，通常ϵ<7ms。
    • 逻辑时钟：中心化授时的方式--时间戳预言机（TSO），好处是无需硬件的支持

共识协议

Quorum NWR模型

  • 三要素：

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

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

  • 引起的并发更新问题

    • 如果允许数据被覆盖，则并发更新容易引起一致性问题

RAFT协议

  • 概述

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

  • 三种角色

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

  • 四种定义：

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

  • 状态转移：

RAFT协议

中文版文献：github.com/maemual/raf…

  • 概述

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

  • 三种角色

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

  • 四种定义：

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

  • 状态转移：

RAFT协议中，Leader写成功日志Log20但未同步给Followers后宕机，Follower重新选举后产生一条新日志Log20，这时Leader重启，整个系统发现两种不一样的Log20的记录，请问如何区分并拒掉前面的Log20？

答：

在RAFT协议中，如果Leader写入了一条成功日志Log20但没有在宕机前与Followers同步，
随后Follower重新选举产生了一条新日志Log20，当原先的Leader重启时，
系统发现两种不同的Log20记录，为了区分并拒绝先前的Log20，系统使用了term编号的概念。
每个日志条目都被分配了一个term编号，这是在创建条目时leader的term。
具有较高term编号的日志条目被认为是更近的，因此被采纳为正确的。
在这种情况下，具有较高term编号的日志将被保留，而具有较低term编号的日志将被拒绝。

RAFT协议中，Stale读是如何产生的？该如何解决Stale读的问题？

答：

Paxos协议

  • Paxos算法与RAFT算法区别：

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

  • 优劣势

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

三、实践练习例子：

MapReduce

  • 设计一个简易的MapReduce系统，思考如何应对故障？

分布式KV

  • 设计一个简易的分布式键值系统，要求具备弹性的能力和达成线性一致

MapReduce

  • 设计一个简易的MapReduce系统，思考如何应对故障？

分布式KV

  • 设计一个简易的分布式键值系统，要求具备弹性的能力和达成线性一致

四、课后个人总结：

本节课学到了很多有关分布式系统的理论知识，个人吸收了一部分。感觉最难的是共识协议，这部分十分抽象,很难理解。同时，这节课的理论知识相当多，也都是精华，需要多多回顾，也希望以后能用得上。同时也感觉到，lamport是真的厉害。
学习参考文献：

image.png

五、引用参考：

【后端专场 学习资料三】第五届字节跳动青训营 - 掘金 (juejin.cn)

avatar
文章
阅读
粉丝