分布式理论基础｜ 青训营笔记

steak0107
194 阅读14分钟

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

分布式概述

什么是分布式

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

优势

  • 去中心化：各机器间通信更便捷
  • 低成本：便宜的服务器集群
  • 弹性：用户访问有波峰有波谷，白天服务，夜间计算，由此有了容器弹性
  • 资源共享：多态机器的数据共建大存储池
  • 可靠性高：应对故障的稳定能力

挑战

  • 普通的节点故障：由于服务器太多，增加发生故障的概率很大，因为各服务器之间出现故障的概率是独立的
  • 不可靠的网络：网络故障的影响较大，使得程序的处理更加复杂
  • 异构的机器与硬件环境：难保证程序在同一个环境运行，调度到其他机器可能性能很差，性能不可预测
  • 安全：若一个集群被攻破，数据风险很大

image.png

Why-How-What

使用者视角

  • Why
    • 能处理数据爆炸、对存储和计算有大规模运用的诉求
    • 成本低，构建在廉价服务器之上
  • How
    • 分布式框架
    • 成熟的分布式系统
  • What
    • 理清规模、负载、一致性要求等
    • 明确稳定性要求，指定技术方案

学习者视角

  • Why
    • 后端开发必备技能
    • 帮助理解后台服务器之间协作的机理
  • How
    • 掌握分布式理论
    • 了解一致性协议
  • What
    • 把要点深入展开
    • 将所学知识应用于实践

常见的分布式系统

分布式存储

  • Google File System(GFS): google分布式文件系统，20年发表
  • Ceph: 统一的分布式存储系统，涵盖了文件、块、对象
  • Hadoop HDFS: 基于GFS架构的开源分布式文件系统
  • Zookeeper: 高可用的分布式数据管理与系统协调架构

分布式数据库

  • Google Spanner: google可扩展的、全球分布式的数据库
  • TiDB: 开源分布式关系型数据库，国内自研
  • HBase: 开源Nosql非关系型数据库
  • MongoDB: 文档数据库

分布式计算

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

系统模型

故障模型

  • Byzantine failure: 节点可以任意篡改发送给其他节点的数据
  • Authentication detectable byzantine failure(ADB): Byzantine failure的特例；节点可以篡改数据，但不能伪造其他节点的数据
  • Performance failure: 节点未在特定时间段内收到数据，即时间太早或太晚，故障和非故障的叠加态，若响应太慢是无法接受的，很难处理
  • Omission failure: 节点收到数据的时间无限晚，即收不到数据，会更好处理一些
  • Crash failure: 在Omission failure的基础上，增加了节点停止响应的假设，也持续性地Omission failure，宕机了
  • Fail-stop failure: 在Crash failure的基础上增加了错误可检测的假设，即知道状态也知道原因

image.png

现实中常见故障

image.png

拜占庭将军问题

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

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

有两个解决方案：

  • 方案一：同时发生N个信使，任何一个达到对方军队，都算成功
  • 方案二：设置超时时间，发生后未在一定时间内返回，则加派信使(也常常是现实中的选择)

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

基于方案二，该思路应用到现实中，如TCP三次握手是在两个方向确认包的序列号，增加了超时重试，是两将军问题的一个工程解

问题推广

image.png

拜占庭问题被数学论证，即在存在消息丢失的不可靠信道上试图通过消息传递的方式达到一致性是不可能的。

在中本聪发明比特币以前，世界上并没有一个非常完美的方法来解决“拜占庭将军问题” 

究其根底，“拜占庭将军问题”最终想解决的是互联网交易、合作过程中的四个问题： 

（1）信息发送的身份追溯

（2）信息的私密性

（3）不可伪造的签名

（4）发送信息的规则

“拜占庭将军问题”其实就是网络世界的模型化

仅拿比特币世界来说，我们可以将每一个比特币交易账号看作一个将军，这些账号分布在世界各地，无法聚在一起，很可能会有恶意账号，账号之间的沟通也很可能因为机器坏了、网络断了、黑客攻击等受到破坏，并且有关账号是不是要支付、具体支付多少的讨论也会浪费很多时间。

问题解决

区块链轻而易举地解决了这一问题，它为信息发送加入了成本，降低了信息传递的速率，而且加入了一个随机元素使得在一定时间内只有一个将军可以广播信息。这里所说的成本就是区块链系统中基于随机哈希算法的“工作量证明”，哈希算法所做的事情就是计算获得的输入，得到一串64位的随机数字和字母的字符串。

区块链系统计算的输入数据是指节点发送的当前时间点的整个总账。当前计算机的算力使其可以实时计算出单个哈希值，但是区块链系统只接受前13个字符是0的哈希值结果作为“工作量证明”。而前13个字符是0的哈希值是非常罕见的，需要整个网络花费10分钟的时间才在数以亿计的数据中找到一个。在一个有效的哈希值被计算出来之前，网络中已经生产了无数个无效值，这就是降低信息传递速率并使得整个系统成功运行的“工作量证明”。

在拜占庭将军问题中，第一个广播信息的将军就是第一个发现有效哈希值的计算机，只要其他将军接收到并验证通过了这个有效哈希值和附着在上面的信息，他们就只能使用新的信息更新他们的总账复制，然后重新计算哈希值。下一个计算出有效哈希值的将军就可以将自己再次更新的信息附着在有效哈希值上广播给大家。然后哈希计算竞赛从一个新的开始点重新开始。由于网络信息的持续同步，所有网络上的计算机都使用着同一版本的总账。

比特币区块链系统找到有效哈希值的时间间隔为10分钟，这是算法设置好的。算法难度每隔两周调整一次就是为了保证这10分钟的间隔，不能多也不能少。每隔10分钟，总账的信息就会在区块链更新并在全网同步一次。因此分散的交易记录是在所有网络上的计算机之间进行对账和同步的。

当个人用户在区块链系统发起一笔交易的时候，他们会使用私钥和公钥为这笔交易签名，而内嵌在比特币系统的标准公钥则承担了加密工具的角色，对应在拜占庭将军问题中，加密工具就是用于签名和验证消息的印章。

因此，哈希算法对信息传递速率的限制加上加密工具使得区块链构成了一个无须信任的数据交互系统。在区块链上，一系列的交易、时间约定、域名记录、政治投票系统或者任何其他需要建立分布式协议的地方，参与者都可以达成一致。(来源百度)

共识和一致性

Eventually consistent(最终一致性)

客户端A读到x=0，当客户端C正在写入时，客户端A和B可能读到0或者1(即读取时间和写入时间重叠)，但是当C写入完成后，A和B最终能读到一致的数据。 我们称这样的一致性为Eventually consistent(最终一致性)

image.png

Linearizability(线性一致性)

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

image.png 如果要保证"线性一致性"，多个节点间势必需要进行协商，以寻求一致，这样增加了延迟，系统的可用性便会受损。

时间和事件顺序

定义"happened before"关系。记为"->"。其满足三个条件

  • 如果a和b是在相同节点上的两个事件，a在b之前发生，则定义：a->b
  • 如果事件a表示某个节点发生某条消息，b是另一个节点接收这条消息，则有：a->b
  • 如果有a->b且b->c，则有a->c

当且仅当a不指向b且b不指向a时，称两个事件为并发的(concurrent)。

image.png
不能找出图中若干满足条件的事件，例如p1->r4，其有p1->q2->q4->r3->r4推导而来。

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"
在同一节点内的连续两个事件之间，至少要有一条tick line

image.png

利用逻辑时钟，我们可以对整个系统中的事件进行全序排序，为每个分布式事务，定义一个时间戳。

理论基础

CAP理论

  • C(Consistence) : 一致性，指数据在多个副本之间能够保持一致的特性(严格的一致性)，是线性一致性
  • A(Availability) : 可用性，指系统提供的服务必须一致处于可用的状态，每次请求都能获取到非错的响应 但不能保证获取的数据为最新的数据，关键落在操作上，而线性一致性的关键落在状态上(比如核查)
  • P(Network partitioning) : 分区容错性，分布式系统在遇到任何网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务，除非整个网络环境发生故障

关键点：一个系统中无法百分之百的同时满足CAP，但可以尽可能接近，是衡量系统好坏的标准。

image.png

CAP理论往往运用于数据库领域，同样也适用于分布式存储方向

CAP诞生了三类系统：

  • CA系统：放弃分区容错性，加强一致性和可用性，是传统数据库的代表
  • AP系统：放弃强一致性，追求分区容错性和可用性，例如一些注重用户体验的系统，保证高可用，不少nosql存储系统采用
  • CP系统：放弃可用性，追求一致性和分区容错性，保证数据一致性，例如与钱财安全相关的系统

image.png

ACID理论

事务是数据库管理系统执行过程中的一个逻辑单元，它能够保证一个事务中的所有操作要么全部执行，要不全部不执行。
其具备四个特性：

  • 原子性（Atomicity)
    指事务包含的所有操作要么全部成功，要么全部失败回滚
  • 一致性（Consistency) 一致性是指事务必须使一个数据库从一个一致性状态变换到另一个一致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态 是事务的一致性
  • 隔离性（Isolation)
    隔离性是当多个用户并发访问数据库时，数据库为每一个用户开启的事务，不能被其他事务的操作所干扰，多个并发事务之前要相互隔离
  • 持久性(Durability)
    持久性是指一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的，即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作

BASE理论

BASE 理论是对 CAP 中的一致性和可用性进行一个权衡的结果，是针对理论AP系统而言的，其来源于对大型互联网分布式实践的总结的核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。

  • Basically Available(基本可用)： 假设系统出现了不可预知的故障，但还是能用，相比较与正常的系统而言：响应时间上的损失或功能(降级或切换)上的损失
  • Soft state(软状态)： 允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时
  • Eventually consistent(最终一致性)： 系统能够保证在没有其他新的更新操作的情况下，数据最终一定能够达到一致的状态，因此所有客户端对系统的数据访问最终都能够获取到最新的值

分布式事务

两阶段提交(Two-phase Commit)

分布式事务往往采用两阶段提交：为了使基于分布式系统架构下的所有节点再进行事务提交时保持一致性而设计的一种演算法。

三个假设

  • 引入协调者(Coordinator)类似中转站，和参与者(Participants)，互相进行进行通信
  • 所有节点都采用预写式日志，且日志被写入后即被保持在可靠的存储设备上
  • 所有节点不会永久性损坏，即使损坏后仍然可以恢复

image.png

可能出现的情况

  • C不宕机，P宕机，需要进行回滚操作
  • C宕机，P不宕机，可以起新的协调者，待查询状态后，重复二阶段提交
  • C宕机，P宕机，无法确认此时处于哪个阶段，需要数据库管理员的介入，防止数据库进入一个不一致的状态

image.png

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

在Prepare阶段，如果某个事务参与者反馈失败消息，说明该节点的本地事务执行不成功，必须回滚。

问题

  • 性能问题
    两阶段提交需要多次节点间的网络通信，耗时过大，资源需要进行锁定，徒增资源等待时间
  • 协调者单点故障问题
    如果事务协调者节点宕机，需要另起新的协调者，否则参与者处于中间状态无法完成事务
  • 网络分区带来的数据不一致
    一部分参与者收到了Commit消息，另一部分参与者没收到Commit消息，会导致了节点之间的数据不一致，必须进行回滚

三阶段提交

将两阶段提交中的Prepare阶段，拆成两部分：CanCommit和PreCommit机制，避免写入Prepare的复杂性，先判断能否commit，若不能则不会发起CanCommit。

改进点

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

image.png

解决的问题

  • 单点故障问题
  • 阻塞问题

另外引入超时机制，在等待超时之后，会自动继续进行事务的提交。

问题

  • 依然没有解决性能问题
  • 网络分区场景带来的数据一致性问题

MVCC

乐观锁与悲观锁

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

image.png

概念

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

image.png

共识协议

Quorum NWR模型

是工程中常用的分布式模型。

三要素

  • N: 在分布式存储系统中，有多少份备份数据
  • W: 代表一次成功的更新操作要求至少有w分数据写入成功
  • R: 代表一次成功的读数据操作要求至少有R份数据成功读取

image.png

为了保持强一致性，需要保证W+R>N，否则读到的数据可能是老的。

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

  • 引起的并发更新问题

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

RAFT协议

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

三种角色

  • Leader - 领导者：Leader 负责处理所有的客户端请求，并向Follower同步请求日志，当日志同步到大多数节点上后，通知Follower提交日志
  • Follower - 跟随者：只接受并持久化Leader同步的日志，在Leader告知日志可以提交后，提交日志，当Leader出现故障时，主动推荐自己的为Candidate
  • Candidate - 备选者：Leader选举过程中的临时角色。向其他节点发送请求投票信息。如果获得大多数选票，则晋升为Leader

image.png

四种定义

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

状态转移

image.png

  • Leader选举过程

    • 初始全部为Follower

    • Current Term + 1

    • 选举自己

    • 向其它参与者发起RequestVote请求，retry直到

      • 收到多数派请求，成为Leader，并发送心跳
      • 收到其它Leader的请求，转为Follower，更新自己的Term
      • 收到部分，但未达到多数派，选举超时，随机timeout开始下一轮

  • Log Replication过程：

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

image.png

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

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

  • Stale读：

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

image.png

Paxos协议

Paxos算法与RAFT算法区别

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

优劣势

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

image.png

分布式实践

MapReduce

image.png

分布式KV

image.png

以上内容若有不正之处，恳请您不吝指正！

avatar
文章
阅读
粉丝