#9 分布式理论 | 青训营笔记

一定要快乐啊
118 阅读10分钟

这是我参与「第五届青训营 」伴学笔记创作活动的第 9 天
本次编程学习的基本环境配置如下
OS: macOS 13.1
IDE: Goland 2022.3
Go Version: 1.18

主要内容

  1. 分布式的概念和常见的分布式系统
  2. 故障模型、共识和一致性
  3. CAP理论、ACID理论和BASE理论
  4. 分布式事务、共识协议
  5. 分布式实践

详细内容

分布式概述

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

image.png

优势

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

挑战(不足)

  1. 节点故障的处理
  2. 不可靠的网络传输
  3. 异构的硬件环境
  4. 安全

对于学习者

  1. 分布式理论是后端开发必备技能, 能帮助理解后台服务器之间协作的机理
  2. 分布式理论和一致性协议是分布式理论的重点

常见的分布式系统

分布式存储

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

分布式数据库

  1. Google Spanner: google可扩展的、全球分布式的数据库
  2. TiDB: 开源分布式关系型数据库(底层是RocksDB)
  3. HBase: 开源NoSQL数据库(列式)
  4. MongoDB: 文档数据库

分布式计算

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

系统模型

故障模型(几个概念)

  1. Byzantine Failure: 节点可以任意篡改发送给其他节点的数据
  2. Authentication detectable byzaantine failure: 是Byzantine Failure的特例, 节点可以篡改数据, 但不能伪造其他节点的数据
  3. Performance Failure: 节点未在特定时间内收到数据
  4. Omission failure: 节点收到数据的时间无限晚, 也就是收不到数据
  5. Crash Failure: Omission failure基础上, 增加了节点停止响应的假设, 即继续性地Omission failure
  6. Fail-Stop Failure: 在Crash Failure基础上增加了错误可检测的假设

image.png

拜占庭将军问题: TCP中的三次握手, 如果FIN报文丢失, 会发生什么?(多个节点如何协商的问题) 当有3m+1个将军, 其中m个叛徒时, 可以增加m轮协商, 最终达成一致

共识和一致性

image.png

  1. 最终一致性: 不管中间经历了怎样的传输, A和B最终能拿到一致的数据
  2. 线性一致性: A收到更新的版本x=1后,及时将消息同步给其它客户端, 这样其他客户端立即能获取到x=1. 若要保证线性一致性, 多个节点之间必须要进行协商, 增加了网络通信成本, 降低了系统的可用性

理论基础

CAP理论

  1. C指的是一致性, 数据在多个副本之间能保持一致的特性
  2. A指的是可用性, 系统提供的服务一直处于可用的状态
  3. P指的是分区容错性, 分布式系统在遇到任何网络分区错误的时候, 仍然能够对外提供满足一致性和可用性的服务, 除非整个网络环境都发生的故障

用于数据库领域, 也可以用于分布式存储方向
CA: 放弃分区容错性, 加强一致性和可用性 ==> 传统单机数据库
AP: 放弃一致性(仅保证最终一致性) ==> 注重用户体验(响应时间短)
CP: 放弃可用性 ==> 一致性十分重要的场景, 比如银行交易业务

在网络发生分区的情况下, 往往需要在可用性和一致性之间做出选择, 比如把故障节点的负载转移给备用节点负责.

ACID理论

不得不谈事务了

事务是数据库系统中非常重要的概念, 它是数据库管理系统执行过程中的一个逻辑单元, ACID是事物具有的特性.

  1. A指的是原子性, 事务包含的操作要么全部成功, 要么全部失败回滚
  2. C指的是一致性, 事务必须使数据库从一个一致性状态转换成另一个一致性状态
  3. I指的是隔离性, 当多个用户并发访问数据库使, 数据库为每一个用户开启的事务, 不能被其他事务的操作所干扰
  4. D指的是持久性, 事务一旦提交, 对数据的改变就是永久性的, 即使数据库系统出现故障也能恢复

BASE理论

  1. 由CAP理论发展而来, 是对一致性和可用性权衡的结果
  2. 基本可用：假设系统出现了不可预知的故障, 但还是能用, 尽管相较于正常的系统而言增加了响应时间或者出现了功能上的损失
  3. 软状态：允许系统中的数据存储中间状态, 并认为该状态不影响系统的整体可用性, 也就是允许系统在多个数据副本之间存在数据延时
  4. 最终一致性: 系统能够保证在没有其他新的更新操作的情况下, 数据最终一定能够达到一致性状态.

分布式事务

二阶段提交(Two-phase Commit)

image.png

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

三个假设

  1. 引入协调者和参与者, 互相进行网络通信
  2. 所有节点都采用预写式日志, 且日志被写入后就被保持在可靠的存储设备上
  3. 所有节点不会永久性损坏, 损坏后也能恢复

可能出现的情况

  1. 任意的协调者都没有出现故障, 但有至少一个参与者故障: 需要进行回滚
  2. 任意的参与者都没有出现故障, 但有至少一个协调者故障: 增加协调者, 重复二阶段提交
  3. 存在至少一台协调者和至少一台参与者故障: 无法确定状态, 需要DBA的介入

挑战

  1. 性能问题: 多次网络通信
  2. 协调者单点故障: 参与者无法自主完成协调
  3. 网络分区可能带来数据不一致

三阶段提交

image.png

将Prepare阶段拆成 CanCommit和PreCommit, 引入超时机制, 解决了单点故障问题和阻塞问题, 但可能加剧了性能问题

MVCC(多版本并发控制)

image.png

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

TSO: 采用中心化的授时方式

共识协议

Quorum NWR模型

image.png

  1. N: 分布式存储系统中, 有多少份备份数据
  2. W: 代表一次成功的更新操作要求至少有w份数据写入成功
  3. R: 代表一次成功的读操作要求至少有R份数据成功读取
  4. 条件: W+R > N

RAFT 协议

image.png

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

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

变量, 数据结构

image.png

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

Leader的选举过程

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

两个规则: 在一个任期内每个参与者最多投一票（持久化）; 要成为Leader,必须拿到多数投票

Log Replication过程

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

  1. Leader收到写请求w
  2. 将w写入本地log
  3. 向其它Follower发起AppendEntries RPC
  4. 等待多数派回复
    • 更新本地状态机，返回给客户端
    • 下一个心跳通知Follower上一个Log已经被Committed了
    • Follower也根据命令应用本地状态机
  5. Follower有问题，Leader一直retry
  6. Leader出现问题 ==> 切主

切主

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

  1. Leader发现失去Follower的响应，失去Leader身份
  2. 两个Follower之间一段时间未收到心跳，重新进行选举，选出新的Leader,此时发生了切主3.
  3. Leader自杀重启，以Follower的身份加入进来
  4. 老leader未失去身份，新leader已经选出，产生了“双主”，该如何解决呢 ==> Stale读

Stale读

保证读的强一致

  1. 读操作在lease timeout内，默认自己是leader, 不是则发起一次neartbeat, 等待Commit Index应用到状态机。
  2. Election timeout > lease timeout:新leader上任，自从上次心跳之后一定超过了Election timeout,旧leader大概率能够发现自己的Lease过期

Paxos协议

分布式实践

MapReduce

image.png

  1. Mapper: 将输入分解为多个Job来并行处理, 彼此之间几乎没有依赖关系
  2. Shuffler: 将mapper结果打乱, 防止数据倾斜
  3. Reducer: 对Map阶段的结果进行全局汇总

容错

  1. Mapper故障, 由中心化节点重新发起调度, 加入新的Mapper重新运行该Job
  2. Reducer故障: 重跑Mapper(Mapper发来的信息全部丢失), 代价大

分布式KV

image.png

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

容错

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

弹性

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

引用

  1. 课程PPT bytedance.feishu.cn/file/boxcn4…
avatar
文章
阅读
粉丝