Go 分布式理论 | 青训笔记

用户6214681127813
180 阅读11分钟

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

Go 分布式理论

分布式概述

什么是分布式

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

  1. 去中心化
  2. 低成本
  3. 弹性
  4. 资源共享
  5. 可靠性高 挑战
  6. 普遍的节点故障
  7. 不可靠的网络
  8. 异构的机器与硬件环境
  9. 安全

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) :Byzantine failure的特例;节点可以篡改数据，但不能伪造其他节点的数据
  • Performance failure :节点未在特定时间段内收到数据，即时间太早或太晚
  • Omission ailure :节点收到数据的时间无限晚，即收不到数据
  • Crash filure 在 omission filure的基础上，增加了节点停止响应的假设，也即持续性地omission ailure
  • Filstip filure在Crash filure的基础上增加了错误可检测的假设
故障描述可能的类型
磁盘故障磁头不寻道、盘片不转、磁介质损伤等。年发生率1 -2%Fail-stop
磁盘坏道、怀块磁头划伤引起坏道，或受宇审射线影响晶体管产生位反转Fail-stop,ADB
服务器主板、板卡故障可能是风扇故障，或灰尘引起的短路，或SCSIRAID卡造成的死机Crash
网络故障电源故障、背板故障等网卡位反转、 网络流量大造成大量丢包等Byzantine,Omission
网络分区网络引起节点形成不同的子集子集中网络相通 ，子集间网络不通Performance
内存故障内存出错造成的数据被基改分为UE、 CE两种ADB
线缆故障服务器光模块频繁up或downPerformance,Omission
内核崩溃内核内部的致命错误产生的kernel panicCrash
CPU故障年故障率接近1%Omission,Crash
电源故障服务器失去电力支排Omission
软件故障如进程crash内存踩坏状态不致配置错误软件bug等Byzantine

共识和一致性

  • 客户端A读到x=0 ,当客户端C正在写入时客户端A和B可能读到0或者1。但是当C写入完成后，A和B最终能读到一致的数据。我们称这样的一致性为Eventually consistent (最终一致性)
  • 当客户端A读到更新的版本x-1后及时将消息同步给其他客户端，这样其他客户端立即能获取到x=1。我们称这样的一致性为Linearizability (线性一致性)
  • 如果要保证"线性”一致性,多个节点间势必需要进行协商，以寻求致。这样增加了延迟，系统可用性便会受损

时间和事件顺序

  • 1978年Leslie Lamport发表在Communications of the ACM上的论文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)

CAP理论

选项描述
C(Consistence)一致性，指数据在多个副本之间能够保持一 致的特性(严格的一 致性)
A(Avllabilty)可用性，指系统提供的服务必须一直处于可用的状态， 每次请求 都能获取到非错的响应一但是不保证获取的数据为最新数据
P (Network partitioring)分区容错性，分布式系统在遇到任何网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务，除非整个网络环境都发生了故障
  • 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 )， 互相进行网络通信
    • 所有节点都采用预写式日志，且日志被写入后即被保持在可靠的存储设备上
    • 所有节点不会永久性损坏，即使损坏后仍然可以恢复

Prepare阶段

graph TD
Coordinator --Prepare--> A(Participants 1)
Coordinator --Prepare--> B(Participants 2)
A(Participants 1)--Done-->Coordinator 
B(Participants 2)--Done-->Coordinator

Commit阶段

graph TD
Coordinator --Commit--> A(Participants 1)
Coordinator --Commit--> B(Participants 2)
A(Participants 1)--Ack-->Coordinator 
B(Participants 2)--Ack-->Coordinator
  • 可能出现的情况
    • Coordinator不宕机，Participant宕机。如下图所示，需要进行回滚操作
    • Coordinator宕机，Participant不宕机。可以起新的协调者，待查询状态后，重复二阶段提交情况
    • Coordinator宕机，Participant宕机 回滚:在Prepare阶段,如果某个事务参与者反馈失败消息，说明该节点的本地事务执行不成功，必须回滚。

Prepare阶段失败

graph TD
Coordinator --Prepare--> A(Participants 1)
Coordinator --Prepare--> B(Participants 2)
A(Participants 1)--Done-->Coordinator 
B(Participants 2)--Fail-->Coordinator

回滚

graph TD
Coordinator --Rollback--> A(Participants 1)
Coordinator --Rollback--> B(Participants 2)
A(Participants 1)--Ack-->Coordinator 
B(Participants 2)--Ack-->Coordinator

情况3 :无法确认状态，需要数据库管理员的介入工防止数据库进入一个不一致的状态。

两阶段提交需注意的问题

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

三阶段提交

三阶段提交Vs两阶段提交

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

  • 解决了两个问题
    • 单点故障问题
    • 阻塞问题 另外引入超时机制在等待超时之后 ，会继续进行事务的提交
sequenceDiagram
Coordinator->>Particpants: 询问是否可以执行CanCommit
Particpants-->>Coordinator: 可以则进入PreCommit阶段失败或超时则退出
Coordinator-)Particpants: 询问是否可以执行PreCommit
Particpants-->>Coordinator: 可以则进入DoCommit阶段失败或超时则Rollback
Coordinator-)Particpants: 向所有人提交事物请求DoCommit
Particpants-->>Coordinator: 反馈提交结果Ack

MVCC

  • 悲观锁：操作数据时直接把数据锁住，直到操作完成之后才会释放锁；上锁期间其他人不能修改数据
  • 乐观锁：不会上锁，只是在执行更新时判断别人是否操作数据,只有冲突时才放弃操作
  • MVCC是一种并发控制的方法，维持一个数据的多个版本使读写操作没有冲突。所以既不会阻塞写，也不阻塞读。MVCC为每个修改保存一个版本，和事务的时间戳相关联。可以提高并发性能，解决脏读的问题。

共识协议

Quorum NWR模型

  • Quorum NWR三要素
    • N :在分布式存储系统中，有多少份备份数据
    • w:代表一次成功的更新操作要求至少有w份数据写入成功
    • R:代表一次成功的读数据操作要求至少有R份数据成功读取 为了保证强一致性需要保证W+R>N
graph TD
Read --> 副本1
Read --> 副本2
Read --> 副本3
Write --> 副本1
Write --> 副本2
Write --> 副本3

N=3,W=2,R=2

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

  • 读者如果读到副本1和副本2 ,得出V= 3的结论如果读到副本2和副本3，得出V= 2的结论
  • 问题根源:允许数据被覆盖 | | 副本1 | 副本2 | 副本3 | | --- | --- | --- | --- | | 初始值（V） | v1=1 | v1=1 | v1=1 | | 第一次写 | v2=2 | v2=2 | v1=1 | | 第二次写 | v3=3 | v2=2 | v2=2 |

RAFT协议

  • Raft协议是一种分布式致性算法(共识算法)， 即使出现部分节点故障，网络延时等情况，也不影响各节点，进而提高系统的整体可用性。Raft是使用较为广 泛的分布式协议。-定意义上讲，RAFT也使用了Quorum机制。
    • 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+ 1
  • 选举自己
  • 向其它参与者发起RequestVote请求，retry直到
    • 收到多数派请求 ，成为Leader ，并发送心跳
    • 收到其它Leader的请求，转为Follower，更新自己的Term
    • 收到部分，但未达到多数派，选举超时，随机timeout开始下一轮

Log Replication过程: 新Leader产生, Leader和Followe不同步，Leader强制覆盖Followers的不同步的日志

  • Leader收到写请求w
  • 将w写入本地og
  • 向其它Follower发起AppendEntries RPC4
  • 等待多数派回复
    • 更新本地状态机，返回给客户端
    • 下一个心跳通知Follower上一个Log已经被Committed了
    • Follower也根据命令应用本地状态机
  • Follower有问题，Leader一直retry

切主

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

Stale读

  • 发生Leader切换，old leader收到了读请求。如果直接响应，可能会有Stale Read。 如何解决?
  • 解决方案，保证读的强一致
  • 读操作在lease timeout内，默认自己是leader ;不是则发起一次heartbeat.等待Commit Index应用到状态机。
  • Election timeout > lease timeout:新leader上任，自从上次心跳之后定超过了Election timeout,Eleader大概率能够发现自己的Lease心期

Paxos协议

Paxos算法与RAFT算法区别

  1. Multi-Paxos可以并发修改日志，而Raft写日志操作必 须是连续的
  2. Multi-Paxos可以随机选主，不必最新最全的节点当选Leader
  • Paxos优势:写入并发性能高，所有节点都能写入
  • Paxos劣势:没有一个节点有完整的最新的数据，恢复流程复杂，需要同步历史记录
ProposersAcceptors
1)获取Proposal ID N
2)向所有Acceptors广播
3)如果n> min proposal则min proposal;= n,返回accepted_value和Proposal
4)接受过半数回复，选择Proposal最大的accepted value作为共识
5)第二阶段，广播Accept(nvalue)到所有节点
6)如果n> =min proposal则minproposal:= n,accepted value;=value,本地持久化，返回
7)接收过半请求如果有果，更新新的提议，跳转1

分布式实践

MapReduce

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

分布式KV

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