分布式基础｜青训营笔记

这是我参与【第五届青训营】伴学笔记创作活动的第8天。

一、重点知识

• 分布式概述：优劣势，挑战，常见的分布式系统
• 系统的故障模型，共识、一致性
• 三大理论基础：CAP、ACID、BASE
• 二阶段、三阶段提交 MCVCC
• RAFT、Paxos算法

二、详细知识点

1. 分布式概述

1.1 什么是分布式

• 计算机程序的集合
• 程序利用跨多个独立计算节点的计算资源来实现共同目标
• 实现分布式计算、分布式存储、分布式数据库

1.2 优势

• 去中心化：容灾
• 低成本：较多服务器/大容量服务器
• 弹性：波峰波谷分离
• 资源共享
• 可靠性高

1.3 挑战

• 普遍的节点故障：大量服务器一定会有发生故障的节点
• 不可靠的网络
• 异构机器与硬件环境：程序可能在不同环境运行情况不同
• 安全：被攻破后会发生大面积问题

1.4 why-how-what

• 使用者视角
  • why
    • 数据爆炸：存储计算有大规模运用诉求
    • 成本低：构建在廉价服务器上
  • how
    • 分布式框架
    • 成熟的分布式系统
  • what
    • 理清规模、负载、一致性要求
    • 明确稳定性要求，制定技术方案
• 学习者视角
  • why
    • 后端开发必备
    • 帮助理解后台服务器之间协作的机理
  • how
    • 掌握分布式理论
    • 了解一致性协议
  • what
    • 深入展开要点，针对难点搜索资料
    • 将知识用于实践

1.5 常见的分布式系统

• 分布式存储
  • GFS：google分布式文件系统
  • Ceph：统一分布式存储系统
  • Hadoop HDFS：基于GFS架构的开源分布式文件系统
  • Zookeeper：高可用分布式数据管理、系统协调框架
• 分布式数据库
  • Google Spanner：google可扩展全球分布式数据库
  • TiDB：开源分布式关系型数据库
  • HBase：开源NoSQL数据库
  • MongoDB：文档数据库
• 分布式计算
  • Hadoop：基于MapReduce分布式计算框架
  • Spark：在Hadoop基础上使用内存存储数据
  • YARN：分布式资源调度

2. 系统模型

2.1 故障模型

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

2.2 真实故障距离

故障	描述	可能类型
磁盘故障	磁头不寻道、盘片不专、磁介质损伤等（年发生率1-2%）	Fail-stop
磁盘坏道、坏块	磁头划伤引起坏道、宇宙射线影响晶体管产生位反转	Fail-stop、ADB
服务器主板、板卡故障	风扇、灰尘短路、SCSI/RAID卡造成死机	Crash
网络故障	电源、背板，网卡位反转、网络流量大丢包	Byzantine、Omission
网络分区	网络引起节点形成不同子集，子集内部相通互相不通	Performance
内存故障	内存出错造成数据被篡改，UE、CE	ADB
线缆故障	服务器光模块频繁up/down	Performance、Omission
内核崩溃	内核内部致命错误，kernel panic	Crash
CPU故障	年故障率1%	Omission、Crash
电源故障	没电了	Omission
软件故障	进程Crash、内存踩坏、状态不一致、配置错误、bug	Byzantion，Crash

2.3 Byzantine将军问题

要么不作战，要么同时进攻；只能派出信使传递。 结论：两支军队无法达成共识。

• 解决方案
  • 同时发送N个信使，任何一个到了就算成功
    • 问题：仍然可能无法达成共识
  • 设置超时时间，一段时间内未返回则重试
• 即使保证消息传递成功，也不能保证达成共识
• TCP三次握手是在两个方向确认包的序列号，是一个工程解
• 将军问题的拓展
  • 三将军问题会导致不一致
  • 四将军则可以保证一致，但是需要增加一轮协商
  • 3m+1将军，其中m叛徒时，通过m轮协商可以达成一致

2.4 共识和一致性

• 最终一致性：最终可以读取到一致的数据 Eventually Consistent
• 线性一致性：当某一客户端读到新版本后，立即同步给其他客户端 Linearizability
• 保证线性一致性，多个节点间需要进行协商寻求一致，增加延迟损伤可用性

2.5 时间和事件顺序

• 并发
  • 定义happened before作为 $\rightarrow$
  • 如果ab是在相同节点两个事件，a在b前发生 则有$a\rightarrow b$
  • 如果事件a表示某节点发送某消息，b为另一节点接受消息，则$a\rightarrow b$
  • 如果$a\rightarrow b\ \& \ b\rightarrow c, \Rightarrow a\rightarrow c$
  • 当且仅当$a \not \rightarrow b \ \& \ b \not \rightarrow a$, 两个事件为并发的（concurrent）
• Lamport逻辑时钟
  • 对于每一个节点Pi定义时钟Ci为一个函数，为任意的事件a赋值编号Ci(a)
  • 如果a和b是在相同节点Pi上的两个事件，a在b之前发生则有Ci(a)<Ci(b)
  • 如果事件a表示节点Pi发送某条消息，b表示节点Pj接受这条消息，则有Ci(a)<Ci(b)
  • tick line在同一节点的两个连续事件之间必须存在

3. 理论基础

3.1 CAP理论

• CAP
  • Consistence：一致性，数据在多个副本之间保持严格一致
  • Availability：可用性，指系统提供的服务必须一直可用，每次请求可以获取到非错响应——但是不保证数据最新
  • network Partitioning：分区容错性，分布式系统在遇到任何网络故障分区时仍能够对外提供满足一致性可用性的服务，除非整个网络发生故障
• 无法同时实现CAP
  • CA：放弃分区容错，传统的单机数据库
  • AP：放弃强一致性，追求分区容错、可用，注重用户体验
  • CP：放弃可用性，追求一致、分区容错，例如钱财相关系统

3.2 ACID理论

• 事务：是数据库管理系统执行中的一个逻辑单元，保证一个事务中所有操作要么执行要么全都不执行
• 数据库事务拥有四个特性
  • Atomicity 原子性：全部操作要么都成功要么全失败
  • Consistency 一致性：事务必须使数据库从一个一致性状态到另一个一致性状态（执行前和执行后必须一致性状态）
  • Isolation 隔离性：多个用户并发访问数据库时，数据库为每一个用户开启的事务不能被其他事务操作干扰，多个并发事务间相互隔离
  • Durability 持久性：一旦事务被提交，对数据库数据改变是持久性的，即便数据库系统故障也不能丢失提交事务操作

3.3 BASE理论

• 对CAP中一致性可用性权衡的结果
• 三个特性
  • Basically Available 基本可用：即使出现不可预知故障，依然可用 （响应时间上的损失或功能上的损失）
  • Soft state 软状态：允许中间状态，且不影响系统整体可用性，允许系统在多个不同节点数据副本存在数据延时
  • Eventually consistent 最终一致性：系统能保证没有其他新更新操作情况下数据最终达到一致状态，所有客户端对系统数据访问能够获取最新的值

4. 分布式事务

4.1 二阶段提交 Two-phase commit

• 基于分布式系统架构下所有节点在进行事务提交时保持一致的算法
• 三个假设
  • 引入协调者coordinator和参与者participants互相进行网络通信
  • 所有节点采用预写日志，且日志被写入后即被保持在可靠存储设备上
  • 所有节点不会永久性损坏，损坏后依然可以恢复
• 可能出现的情况
  • coordinator不宕机，participant宕机，需要进行回滚（prepare阶段若某个事务参与者反馈失败，则该节点本地事务执行不成功，必须回滚）
  • coordinator宕机，participant不宕机，可以起新的coordinator，查询状态后重复二阶段提交
  • 两个都宕机：无法确认状态，需要数据库管理员介入防止数据库进入不一致状态
• 需要注意的问题
  • 性能问题：多次节点间网络通信，耗时过大，资源需要锁定，增加资源等待时间
  • 协调者单点故障：协调者节点宕机需要另起新的协调者，否则参与者处于中间状态无法完成
  • 网络分区带来数据不一致：一部分收到commit 一部分没收到，造成节点数据不一致

4.2 三阶段提交

• 将两阶段提交中的prepare阶段拆成两部分
  • canCommit和preCommit，最后doCommit
  • 解决单点故障和阻塞问题
  • 引入超时机制，等待超时之后继续进行事务提交
• 依然没有解决所有问题
  • 性能问题：增加更多通信
  • 网络分区带来数据一致性问题更加严重

4.3 MVCC

• 锁类型
  • 悲观锁：操作数据时直接把数据锁住直到操作完成后才释放锁；上锁期间其他人不能修改数据
  • 乐观锁：不会上锁，只是在执行更新时判断别人是否修改数据，冲突时才会放弃操作
• 并发控制：维持一个数据的多个版本使读写操作没有冲突，所以既不会阻塞写也不会阻塞读
• 为每个修改保存一个版本，和事务时间戳相关联，可以提高并发性，解决dirty read
• 时间戳
  • TrueTime API物理时钟，偏差1-7ms
  • 时间戳预言机TSO：中心化授时方式，协调者向中心化节点获取时钟，但需要每个节点进行交互，网络通信成本。需要考虑低延迟、高性能、容错等。

5. 共识协议

5.1 Quorum NWR模型

• 三要素
  • N：在分布式存储系统中多少备份数据
  • W：一次成功更新需要至少w份数据成功
  • R：一次成功读需要至少R份数据读取成功
• 保证强一致性需要W+R>N （必要不充分）
• 简化版的一致性模型，将CAP的选择交给用户
• 问题：并发更新问题，读取不同的R份数据可能读到不同结论
  • 允许数据被覆盖是问题根源

5.2 RAFT协议

• 一种分布式一致性算法（共识算法）
• 出现部分节点故障、网络延时等情况也不影响各节点 提高系统整体可用性
• 三种角色
  • Leader：领导者，通常一个系统中是一主leader多从follower。leader负责处理所有客户端请求，并向follower同步请求日志。当日志同步到大多数节点上后，通知follower提交日志
  • follower：跟随者，不发送任何请求，接受并持久化leader同步的日志，在leader告知日志可以提交后提交日志。当leader出现故障时推荐自己为candidate
  • candidate：备选者，leader选举过程中的临时角色。向其他节点发送请求投票信息，若获得大多数选票则晋升为leader
• 其他概念
  • log 日志：节点之间同步信息，只追加写进行同步，解决数据被覆盖
  • term 任期号：单调递增，每个term内最多只有一个leader
  • committed：日志被复制到多数派节点即可认为已经被提交
  • applied：日志被应用到本地状态机，执行log中命令修改内存状态
• Leader选举过程
  • 初始状态全部为follower
  • current term++
  • 选举自己
  • 向其他参与者发起requestVote请求，retry直到
    • 收到多数派请求成为leader 并发送心跳
    • 收到其他leader请求，转为follower，更新自己term
    • 收到部分，但未达到多数派，超时进下一轮投票
  • 规则
    • 一个任期内每个参与者最多投一票
    • 成为leader必须拿到多数投票：可能无法选出而不可用
• Log Replication过程：新leader产生，leader和follower不同步，leader强制覆盖folowers的不同步的日志
  • leader收到写请求w
  • 将w写入本地log
  • 向其他follower发起AppendEntries RPC
  • 等待多数派回复
    • 更新本地状态机，返回客户端
    • 下一个心跳通知follower上一个log已经被committed了
    • follower也根据命令应用本地状态机
  • follower有问题，leader一直retry
• 切主：当leader出现问题则需要重新进行选举
  • leader失去follower响应则失去leader身份
  • 两个follower之间一段时间未收到心跳，重新进行选举，选出新leader，发生切主
  • leader自杀重启，以follower身份进入
  • 问题：可能发生双主
• Stale读：发生leader切换时，old leader收到了读请求，如果直接响应会发生stale read
  • 解决方法，保证强读一致
  • 读操作在leasetimeout内默认自己是leader，不是则发起一次heartbeat等待commit index应用到状态机
  • election timeout > lease timeout：新leader上任，自从上次心跳之后一定超过了选举timeout，旧leader大概率能发现自己的lease过期

5.3 Paxos协议

• 与RAFT的区别
  • multi-paxos可以并发修改日志，而Raft写日志操作必须连续
  • multi-paxos可以随机选主，不必最新最全的节点当选leader
• 优势：写入并发性能高，所有节点都能写入
• 劣势：没一个节点有完整的数据，恢复流程复杂需要同步历史数据

三、分布式实践例

• MapReduce
  • 三阶段
    • Mapper：将输入分解为多个job来并行处理，彼此没有依赖关系
    • Shuffler：将mapper结果打乱防止数据倾斜
    • reducer：对mapper的结果进行全局汇总
  • 容错
    • mapper故障：中心化节点重新发起调度，重启mapper重跑hob
    • reducer故障：重跑mapper，代价大
• 分布式KV
  • 架构
    • 将海量结构化数据根据key分成不同region
    • 每个region构建单机KV数据库
    • region之间形成RAFT groups做到强一致
  • 容错
    • 当node故障时，通过raft learner模式进行数据修复
  • 弹性
    • 当出现局部key热点或数据膨胀时，region可以进行split操作，分成两个子region
    • 反之收缩时可以进行merge操作

四、课后总结

本节课主要介绍了分布式系统的基础、挑战以及实现，很多内容在第四期青训营大数据方向的课程中已经进行过学习。本节课程包含大量基础知识以及算法，需要在课后时间进行深入研究。

五、引用资料

• 学习手册