分布式概述

什么是分布式

  • 分布式系统是计算机程序的结合，这些程序利用跨多个独立计算节点的计算资源来实现共同的目标，可以分为分布式计算，分布式存储，分布式数据库等
  • 优势：
    • 去中心化
    • 低成本
    • 弹性
    • 资源共享
    • 可靠性高
  • 挑战：
    • 普遍的节点故障
    • 不可靠的网络
    • 异构的机器与硬件环境
    • 安全

Why-How-What

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

常见的分布式系统

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

系统模型

故障模型

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

拜占庭将军问题

  • 引入：

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

  • 结论：

    • 两将军问题是被证实无解的电脑通信问题，两支军队理论上永远无法达成共识

  • 方案：

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

  • 共识与消息传递的不同：即使保证了消息传递成功，也不能保证达成共识

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

  • 三将军问题

    • 拜占庭将军考虑更加普适的场景，例如 3 个将军 ABC 互相传递消息，消息可能丢失，也可能被篡改，当有一个将军是“叛徒”（即出现拜占庭故障）时，整个系统无法达成一致
    • 如果没有”叛徒“，无论各自观察到怎样的敌情，总能达成一致的行动
    • 由于“叛徒”C 的存在，将军 A 和将军 B 获得不同的信息。这样将军 A 获得 2 票进攻 1 票撤退的信息，将军 B 获得 1 票进攻 2 票撤退的信息，产生了不一致

  • 四将军问题

    • 考虑当 4 个将军，只有一个叛徒的场景，将军 D 作为消息分发中枢，约定如果没收到消息则执行撤退
    • 步骤：
      • 如果 D 为“叛徒”，ABC 无论收到任何消息，总能达成一致
      • D 为“忠将”，ABC 有 2 人将 D 的消息进行正确的传递，同样能保证最终决策符合大多数
    • 进而能够证明，当有 3m+1 个将军，m 个“叛徒”时，可以进行 m 轮协商，最终达成一致

共识和一致性

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

    • 读请求和写请求并发时可能读到旧值
  • 当客户端 A 读到更新的版本 x=1 后，及时将消息同步给其他客户端，这样其他客户端立即能获取到 x=1，称这样的一致性为 Linearizability（线程一致性）

    • 一旦某个读取到新值，所有客户端都必须返回新值
  • 如果要保证”线程“一致性，多个节点间势必需要进行协商，以寻求一致。这样增加了延迟，系统可用性便会受损

时间和事件顺序

  • 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 且 b->c ，则有 a->c
    • 当且仅当 a -/-> b 且 b -/-> a 时，我们称两个事件为并发的（concurrent）
  • Lamport 逻辑时钟
    • 对于每一个节点 Pi 我们定义时钟 Ci 为一个函数，它为任意的事件 a 赋值编号为 Ci(a)
      • 如果 a 和 b 是在相同节点 pi 上的两个事件，a 在 b 之前发生，则有 Ci(a)<Ci(b)
      • 如果事件 a 表示节点 pi 发送某条消息，b 表示节点 Pj 接受这条消息，则有 Ci(a)<Cj(b)
    • 在同一节点内的连续两个事件之间，至少要有一条 tick line
    • 利用逻辑时钟，我们可以对整个系统中的事件进行全序排序

理论基础

CAP 理论

  • CAP 理论往往运用于数据库领域，同样可以适用于分布式存储方向
  • CA：放弃分区容错性，加强一致性和可用性，其实就是传统的单机数据库的选择
  • AP：放弃一致性（这里说的是一致性是强一致性），追求分区容错性和可用性，例如一些注重用户体验的系统
  • CP：放弃可用性，追求一致性和分区容错性，例如与钱财安全相关的系统

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

ACID 理论

  • 事务是数据库系统中非常重要的概念，它是数据库管理系统执行过程中的一个逻辑单元，它能够保证一个事务中的所有操作要么全部执行，要么全都不执行
  • 数据库事务拥有四个特性ACID：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability）
  • 原子性（A）：原子性是指事务包含的所有操作要么全部成功，要么全部失败回滚
  • 一致性（C）：一致性是指事务必须使数据库从一个一致性状态变换到另一个一致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态
  • 隔离性（I）：隔离性是当多个用户并发访问数据库时，数据库为每一个用户开启的事务，不能被其他事务的操作所干扰，多个并发事务之间要相互隔离
  • 持久性（D）：持久性是指一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的，即使是在数据库系统遇到故障的情况下也不会丢失提交事务的操作

BASE 理论

  • Base 理论是对 CAP 中一致性和可用性权衡的结果，其来源于对大型互联网分布式实践的总结，是基于 CAP 定理逐步演化而来的，其核心思想是：
    • Basically Available(基本可用)：假设系统，出现了不可预知的故障，但还是能用，相比较正常的系统而言：响应时间上的损失，或功能上的损失
    • Soft state（软状态）：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延迟
    • Eventually consistent（最终一致性）：系统能够保证在没有其他新的更新操作的情况下，数据最终一定能够达到一致的状态，因此所有客户端对系统的数据访问最终都能够获取到最新的值

分布式事务

二阶段提交

  • 二阶段提交（Two-phase Commit）：为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种演算法
  • 三个假设：
    • 引入协调者（Coordinator）和参与者（Participants），互相进行网络通信
    • 所有节点都采用预写式日志，且日志被写入后即被保持在可靠的存储设备上
    • 所有节点不会永久性损坏，即使损坏后仍然可以恢复
  • 可能出现的情况：
    • 1、Coordinator 不宕机，Participant 宕机。需要进行回滚操作
    • 2、Coordinator 宕机，Participant 不宕机。可以引起新的协调者，待查询状态后，重复二阶段提交
    • 3、Coordinator 宕机，Participant 宕机。无法确定状态，需要数据库管理员的介入，防止数据库进入一个不一致的状态
  • 回滚：在 Prepare 阶段，如果某个事务参与者反馈失败消息，说明该节点的本地事务执行不成功，必须回滚
  • 需注意的问题：
    • 性能问题
      • 两阶段提交需要多次节点间的网络通信，耗时过大，资源需要进行锁定，徒增资源等待时间
    • 协调者单点故障问题
      • 如果事务协调者节点宕机，需要另起新的协调者，否则参与者处于中间状态无法完成事务
    • 网络分区带来的数据不一致
      • 一部分参与者收到了 Commit 消息，另一部分参与者没收到 Commit 消息，会导致节点之间数据不一致

三阶段提交

  • 三阶段提交 vs 两阶段提交
    • 将两阶段提交中的 Prepare 阶段，拆成两部分：CanCommit 和 PreCommit 机制
  • 解决了两个问题：
    • 单点故障问题
    • 阻塞问题
  • 另外引入超时机制，在等待超时之后，会继续进行事务的提交

MVCC

  • MVCC 是一种并发控制的方法，维持一个数据的多个版本使读写操作没有冲突。所以既不会阻塞写，也不阻塞读。MVCC 为每个修改保存一个版本，和事务的时间戳相关联，可以提高并发性能，解决脏读的问题
  • 版本的选取：
    • 物理时钟：提供 TrueTime API，有 Master 节点维持一个绝对时间，保证各个服务器之间时钟误差控制在 ϵ 内，通常 ϵ<7ms
    • 逻辑时钟：时间戳预言机（TSO），采用中心化授时的方式，所有协调者向中心化节点获取时钟，优点是算法简单，实现方便，但需要每个节点都与他进行交互，会产生一些网络通信的成本。TSo 的授时中就需要考虑低延迟、高性能以及更好的容错性

共识协议

Quorum NWR 模型

  • Quorum NWR 三要素
    • N：在分布式存储系统中，有多少份备份数据
    • W：代表一次成功的更新操作要求至少有 w 份数据写入成功
    • R： 代表一次成功的读数据操作要求至少有 R 份数据成功读取
  • 为了保证强一致性，需要保证 W+R>N
  • Quorum NWR 模型将 CAP 的选择交给用户，是一种简化版的一致性模型
  • 引起的并发更新问题
    • 如果允许数据被覆盖，则并发更新容易引起一致性问题

RAFT 协议

  • Raft 协议是一种分布式一致性算法（共识算法），即使出现部分节点故障，网络延时等情况，也不影响各节点，进而提高系统的整体可用性。Raft 是使用较为广泛的分布式协议。一定意义上讲，RAFT 也使用了 Quorum 机制
  • 三种角色：
    • Leader - 领导者：Leader 负责处理所有的客户端请求，并向 Follower 同步请求日志，当日志同步到大多数节点上后，通知 Follower 提交日志
    • Follower - 跟随者：不会发送任何请求，接受并持久化 Leader 同步的日志，在 Leader 告知日志可以提交后，提交日志。当 Leader 出现故障时，主动推荐自己为 Candidate
    • Candidate - 备选者：Leader 选举过程中的临时角色，向其他节点发送请求投票信息，如果获得大多数选票，则晋升为 Leader
  • 四种定义：
    • Log（日志）：节点之间同步的信息，以只追加写的方式进行同步，解决了数据被覆盖的问题
    • Term（任期号）：单调递增，每个 Term 内最多只有一个 Leader
    • Committed：日志被复制到多数派节点，即可认为已经被提交
    • Applied：日志被应用到本地状态机：执行了 log 中命令，修改了内存状态
  • 状态转移：
  • Leader 选举过程：
    • 1、初始全部为 Follower
    • 2、Current Term + 1
    • 3、选举自己
    • 4、向其它参与者发起 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 已经被 Commited 了
      • Follower 也根据命令应用本地状态机
    • 5、Follower 有问题，Leader 一直 retry
  • 问题：如果 Leader 有问题呢？
  • 切主：
    • 当 Leader 出现问题时，就需要进行重新选举
    • 1、Leader 发现失去 Follower 的响应，失去 Leader 身份
    • 2、两个 Follower 之间一段时间未收到心跳，重新进行选举，选出新的 Leader，此时发生了切主
    • 3、Leader 自杀重启，以 Follower 的身份加入进来
  • 问题：老 Leader 未失去身份，新 Leader 已经选出，产生了”双主“如何解决？
  • Stale 读：
    • 发生 Leader 切换，old leader 收到了读请求。如果直接响应，可能会有 Stale Read
    • 解决方案：保证读的强一致
    • 该操作在 lease timeout 内，默认自己是 Leader；不是则发起一次 heartbeat。等待 Commit Index 应用到状态机
    • Election timeout > least timeout；新 Leader 上任，自从上次心跳之后一定超过了 Election timeout，旧 Leader 大概率能够发现自己的 Lease 过期

Paxos 协议

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

分布式实践

MapReduce

  • Mapper：将输入分解为多个 Job 来并行处理，彼此间几乎没有依赖关系
  • Shuffler：将 maper 结果打乱，防止数据倾斜
  • Reducer：对 map 阶段的结果进行全局汇总
  • 容错：
    • Mapper 故障：由中心化节点重新发起调度，新起 Mapper 重跑 job
    • Reducer 故障：重跑 Mapper，代价大

分布式 KV

  • 架构：
    • 将海量结构化数据根据 Key 分成不同的 Region，每个 Region 构建一个单机 KV 数据库，Region 之间形成 Raft Groups，做到强一致
  • 容错：
    • 当 Node 故障时，通过 Raft Learner 模式进行数据修复
  • 弹性：
    • 当出现局部 Key 热点或数据膨胀时，Region 可以进行 Split 操作，分成两个子 Region，反之收缩时进行 Merge 操作

思考题

许可协议

本文采用 署名-非商业性使用-相同方式共享 4.0 国际 许可协议，转载请注明出处。

分享文章