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

用户4955575447946
93 阅读11分钟
  • 这是我参与「第五届青训营 」伴学笔记创作活动的第 8 天

1. 分布式概述

1.1 什么是分布式

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

优势：

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

挑战：

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

1.2 Why-How-What

使用者视角：

Why：

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

How：

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

What：

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

学习者视角：

Why：

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

How：

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

What：

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

1.3 常见的分布式系统

  • 分布式存储

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

  • 分布式数据库

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

  • 分布上计算

    1. Hadoop： 基于MapReduce分布式计算框架
    2. Spark： 在Hadoop基础上，使用内存来存储数据
    3. YARN： 分布式资源调度

2. 系统模型

2.1 故障模型

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

3. 理论基础

3.1 CAP理论

选项描述
C (Consistence)一致性，指数据在多个副本之间能够保持一致的特性（严格的一致性）
A (Availability)可用性，指系统提供的服务必须一直处于可用的状态，每次请求都能获取非错的响应——但不是保证获取数据为最新数据
P (Network partitioning)分区容错性，分布式系统在遇到任何网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务，除非整个网络环境都发生了故障

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

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

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

3.2 ACID理论

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

数据库事务拥有4个属性：原子性、一致性、隔离性、持久性。

  • 原子性（atomicity）。一个事务是一个不可分割的工作单位，事务中包括的操作要么都做，要么都不做。
  • 一致性（consistency）。事务必须是使数据库从一个一致性状态变到另一个一致性状态。一致性与原子性是密切相关的。
  • 隔离性（isolation）。一个事务的执行不能被其他事务干扰。即一个事务内部的操作及使用的数据对并发的其他事务是隔离的，并发执行的各个事务之间不能互相干扰。
  • 持久性（durability）。持久性也称永久性（permanence），指一个事务一旦提交，它对数据库中数据的改变就应该是永久性的。接下来的其他操作或故障不应该对其有任何影响。

3.3 BASE理论

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

  • 基本可用(Basically Available)： 基本可用是指分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用。电商大促时，为了应对访问量激增，部分用户可能会被引导到降级页面，服务层也可能只提供降级服务。这就是损失部分可用性的体现。
  • 软状态(Soft State)： 软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据至少会有三个副本，允许不同节点间副本同步的延时就是软状态的体现。MySQL Replication 的异步复制也是一种体现。
  • 最终一致性(Eventual Consistency)： 最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。

4. 分布式事务

4.1 二阶段提交

二阶段提交（Two-phase Commit）：为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种演算法。

三个假设：

  1. 引入协调者（Coordinator）和参与者（Participants），互相进行网络通信
  2. 所有节点都采用预写式日志，且日志被写入后即被保持在可靠的存储设备上
  3. 所有节点不会永久性损坏，即使损坏后仍然可以恢复

可能出现的情况：

  1. Coordinator不宕机，Participant宕机。需要进行回滚操作。
  2. Coordinator宕机，Participant不宕机。可以起新的协调者，待查询状态后，重复二阶段提交
  3. Coordinator宕机，Participant宕机。

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

二阶段提交注意问题：

  1. 性能问题
  2. 协调者单点故障文体
  3. 网络分区带来的数据不一致

4.2 三阶段提交

三阶段提交相比于二阶段提交，将两阶段提交中的prepare阶段拆成了CanCommit和PreCommit机制两部分。

解决了：

  1. 单点故障问题
  2. 阻塞问题

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

4.3 MVCC

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

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

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

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

5. 共识协议

5.1 Quorum NWR模型

  • Quorum NWR三要素

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

为了保证强一致性，需要保证w+r>n

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

5.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出现问题时，就需要进行重新选举

    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，旧的leader大概率能够发现自己的Lease过期。

5.3 Paxos协议

Paxos算法与RAFT算法的区别：

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

优势：写入并发性能高，所有节点都能写入

劣势：没有一个节点有完整的最新的数据，恢复流程复杂，需要同步历史记录

avatar
文章
阅读
粉丝