分布式理论 - 现代架构基石 | 青训营笔记

用户2808417629336
159 阅读11分钟

分布式理论 - 现代架构基石

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

思维导图

image.png

课程目标

  • 分布式概述
  • 系统模型
  • 理论基础
  • 分布式事务
  • 共识协议
  • 分布式实践

分布式概述

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

优势：

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

挑战：

  1. 普遍的节点故障
  2. 不可靠的网络
  3. 异构的机器与硬件环境
  4. 安全

Why-How-What

使用者视角：

Why

  1. 数据爆炸，对存储和计算有大规模运用的述求
  2. 成本低，构建在廉价服务器之上

How：

  1. 分布式框架
  2. 成熟的分布式系统

What

  1. 理清规模、负载、一致性要求等
  2. 明确稳定性要求，制定技术方案

学习者视角：

Why

  1. 后端开发必备技能
  2. 帮助理解后台服务器之间协作的机理

How：

  1. 掌握分布式理论
  2. 了解一致性协议

What

  1. 把要点深入展开，针对难点搜索互联网资料进行学习
  2. 将所学知识运用于实践

常见的分布式系统

分布式存储：

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

分布式数据库：

  1. Google Spanner: google可扩展的、全球分布式的数据库。
  2. TiDB:开源分布式关系型数据库
  3. HBase:开源NosqI数据库
  4. MongoDB:文档数据库

分布式计算：

  1. Hadoop:基于MapReduce分布式计算框架
  2. Spark:在Hadoop基础之上，使用内存来存储数据
  3. 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

拜占庭将军问题

  • 两将军问题
    • 定义：
      • 两支军队的将军只能派信使穿越敌方领土互相通信，以此约定进攻时间。该问题希望求解如何在两名将军派出的任何信使都可能被俘虏的情况下，就进攻时间达成共识
    • 结论：
      • 两将军问题是被证实无解的电脑通信问题，两支军队理论上永远无法达成共识
    • TCP是两将军问题的一个工程解
  • 三将军问题：
    • 两个“忠将”A和B，一个“叛徒”C，互相传递消息，消息可能丢失，也可能被篡改，当有一个将军是“叛徒”（即出现拜占庭故障）时，整个系统无法达成一致。
    • 由于“叛徒”C的存在，将军A和将军B获得不同的信息。这样将军A获得2票进攻1票撤退的信息，将军B获得1票进攻2票撤退的信息，产生了不一致
  • 四将军问题：
    • 将军D作为消息分发中枢，约定如果没收到消息则执行撤退
    • 步骤：
      • 如果D为“叛徒”，ABC无论收到任何消息，总能达成一致
      • D为“忠将”，ABC有2人将D的消息进行正确的传递，同样能保证最终决策符合大多数。
    • 进而能够证明，当有3m+1个将军，m个“叛徒”时，可以进行m轮协商，最终达成一致

共识和一致性

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

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

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

时间和事件顺序

1978年L eslie Lamport发表在Communications of the ACM.上的论文Time, Clocks, and the Ordering of Events in a Dis tributed System

我们定义"happened before"关系，记为"→"。其满足如下三个条件:

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

当且仅当a-/->b且b-/->a时，我们称两个事件为并发的(concurrent)。

我们不难在图中找到若干满足条件的事件对，例如p1→r4， 其由p1→q2→q4→r3→r4推导而来

image.png

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理论

image.png

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

  • CA：放弃分区容错性，加强一致性和可用性，其实就是传统的单机数据库的选择
  • AP：放弃一致性（这里说的一致性是强一致性），追求分区容错性和可用性，例如一些注重用户体验的系统
  • CP：放弃可用性，追求一致性和分区容错性，例如与钱财安全相关的系统

image.png

ACID理论

事务是数据库系统中非常重要的概念，它是数据库管理系统执行过程中的一个逻辑单元， 它能够保证一个事务中的所有操作要么全部执行，要么全都不执行。

数据库事务拥有四个特性ACID,即分别是原子性(Atomicity)、一致性(Consistency) 、隔离性(Isolation) 和持久性(Durability)

原子性(A)：原子性是指事务包含的所有操作要么全部成功，要么全部失败回滚。

一致性(C)：一致性是指事务必须使数据库从一个致性状态变换到另一个致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态

隔离性(I)：隔离性是当多个用户并发访问数据库时，数据库为每一个用户开启的事务，不能被其他事务的操作所干扰，多个并发事务之间要相互隔离

持久性(D)：持久性是指一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的，即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作。

image.png

BASE理论

Base理论是对CAP中一致性和可用性权衡的结果，其来源于对大型互联网分布式实践的总结，是基于CAP定理逐步演化而来的。其核心思想是:

Basically Available(基本可用):假设系统出现了不可预知的故障，但还是能用，相比较正常的系统而言:响应时间上的损失，或功能上的损失

Soft state (软状态) :允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。

Eventually consistent (最终一 致性) :系统能够保证在没有其他新的更新操作的情况下，数据最终一定能够达到一致的状态，因此所有客户端对系统的数据访问最终都能够获取到最新的值。

分布式事务

二阶段提交

  • 定义：
    • 二阶段提交（Two-phase Commit）：为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种演算法。
  • 三个假设：
    • 引入协调者和参与者，互相进行网络通信
    • 所有节点都采用预写式日志，且日志被写入后即被保持在可靠的存储设备上
    • 所有节点不会永久性损坏，即使损坏后仍然可以恢复
  • 正常流程：Prepare阶段和Commit阶段
  • 异常流程：Prepare阶段失败 -> 回滚；协调者宕机 -> 重新启用新的协调者；双故障重启 -> 数据库管理员介入
  • 两阶段提交需注意的问题：
    • 性能问题：两阶段需要多次节点间的网络通信，耗时过大，资源需要等待并锁定，增加资源等待时间
    • 协调者单点故障问题：如果事务协调者节点宕机，需要另起新的协调者，否则参与者处于中间状态无法完成事务
    • 网络分区带来的数据不一致：一部分参与者收到了Commit消息，另一部分参与者没收到Commit消息，会导致了节点之间数据不一致

三阶段提交

三阶段提交 vs 两阶段提交

将两阶段提交中的Prepare阶段，拆分两部分：CanCommit和PreCommit机制

解决了两个问题：

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

另外引入超时机制，在等待超时之后，会继续进行事务的提交 屏幕截图 2023-02-02 205359.png

MVCC

image.png 悲观锁：操作数据时直接把数据锁住，直到操作完成后才会释放锁；上锁期间其他人不能修改数据

乐观锁：不会上锁，只是在执行更新时判断别人是否修改数据，只有冲突时才放弃操作

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

Spanner论文里通过TrueTime API提供一个物理时钟的方式。服务器时钟偏差在1到7ms之间。

S1提交事务时间: s1 = max(15, 7 + 7)=15ms

S2提交事务时间: s2=max(13, 12 + 7)=19ms

image.png

另外一种时间戳的实现:时间戳预言机(TSO)，采用中心化的授时方式，所有协调者向中心化节点获取时钟。优点是算法简单，实现方便，但需要每个节点都与他进行交互，会产生一些网络通信的成本。TSO的授时中就需要考虑低延迟，高性能以及更好的容错性。

共识协议

Quorum NWR模型

  • 三要素：

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

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

  • 引起的并发更新问题

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

RAFT协议

概述：

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

三种角色：

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

image.png

四种定义：

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

image.png

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发起AppenEntries RPc
  4. 等待多数派回复
  • 更新本地状态机，返回给客户端
  • 下一个心跳通知Follower上一个Log已经被Committed了
  • Follower也根据命令应用本地状态机
  1. Follower有问题，Leader一直retry

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

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

Stale读：

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

解决方案：保证读的强一致

Paxos协议

  • Paxos算法与RAFT算法区别：

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

  • 优劣势

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

分布式实践

MapReduce

image.png

  • Mapper：将输入分解为多个Job来并行处理，彼时间几乎没有依赖关系
  • Shuffler：将maper结果打乱，防止数据倾斜
  • Reducer：对map阶段的结果进行全局汇总

容错：

  1. Mapper故障：由中心化节点重新发起调度，新起Mapper重跑job
  2. Reducer故障：重跑Mapper，代价大

分布式KV

image.png

架构:

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

容错:

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

弹性:

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

总结：

经过此次课程的学习，了解了分布式理论，但是还是不太熟悉，下课再多熟练熟练，看看掘金上的有关此部分的文章

avatar
文章
阅读
粉丝