分布式理论 | 青训营日记

赚夯大户
105 阅读9分钟

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

这节课主要简述了分布式系统及其基础理论、系统模型和使用的分布式数据库事务方案等。

概述

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

  • Why-How-What

  • 使用者视角：大规模计算存储的述求

  • 学习者视角：后端开发必备技能

  • 常见的分布式系统

  • 分布式存储：GFS、Ceph、HDFS、Zookeeper

  • 分布式数据库：Spanner、TiDB、HBase、MangoDB

  • 分布式计算：Hadoop、YARN、Spark

系统模型

故障模型

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

六种故障模型，从处理的难易程度分类，从上到小，逐渐变易。

拜占庭将军问题

两将军问题

  • 定义：

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

  • 结论：

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

  • TCP是两将军问题的一个工程解

三将军问题

  • 两个“忠将”A和B，一个“叛徒”C，互相传递消息，消息可能丢失，也可能被篡改，当有一个将军是“叛徒”（即出现拜占庭故障）时，整个系统无法达成一致。
  • 由于“叛徒”C的存在，将军A和将军B获得不同的信息。这样将军A获得2票进攻1票撤退的信息，将军B获得1票进攻2票撤退的信息，产生了不一致

四将军问题

  • 将军D作为消息分发中枢，不具有投票权力，约定如果没收到消息则执行撤退，假设4个将军中只有1个“叛徒”；进行2次投票，一次通过将军D进行消息分发，一次不通过将军D，进行“三将军问题”的步骤，对比2次投票的结果。

  • 可能性讨论：

    • 如果D为“叛徒”，ABC无论收到任何消息，总能达成一致
    • D为“忠将”，ABC有2人将D的消息进行正确的传递，同样能保证最终决策符合大多数。

  • 进而能够证明，当有3m+1个将军，m个“叛徒”时，可以进行m轮协商，最终达成一致。

共识和一致性

不同客户端A和B看到客户端C写入，因为时机的不同，产生数据读取的偏差。

  • 最终一致性：客户端A读到x=0，当客户端C正在写入时客户端A和B可能读到0或者1。但是当C写入完成后，A和B最终能读到一致的数据。
  • 线性一致性：当客户端A读到更新的版本x=1后，及时将消息同步给其他客户端，这样其他客户端立即能获取到x=1。

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

时间和时间顺序

  • 定义了计算机系统中的时间和事件顺序，引入happened before和并发的定义，可以以此对分布式系统中的事件进行推导。
  • 根据上述推导，创造了Lamport逻辑时钟的概念，这个概念在分布式理论中具有革命性的意义，帮助我们在一系列分布式事件当中梳理出逻辑的先后关系。利用逻辑时钟，我们可以对整个系统中的事件进行全序排序。

理论基础

CAP理论

分别代表一致性（指数据在多个副本之间能够保持一致的特性）、可用性（指系统提供的服务必须一直处于可用的状态，每次请求都能获取到非错的响应----但是不保证获取的数据为最新数据）、分区容错性（分布式系统在遇到任何网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务，除非整个网络环境都发生了故障），三者无法同时达到。

  • CA系统：传统数据库的代表
  • AP系统：放弃强一致性，保证高可用，不少nosql存储系统采用
  • CP系统：放弃可用性，保证数据一致性

ACID理论

  • ACID理论是针对CA系统而言的，通常在数据库中具有广泛意义
  • 事务是数据库系统中非常重要的概念，它是数据库管理系统执行过程中的一个逻辑单元，它能够保证一个事务中的所有操作要么全部执行，要么全都不执行
  • 数据库事务拥有四个特性ACID：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability）

BASE理论

  • Basically Available(基本可用)：假设系统，出现了不可预知的故障，但还是能用
  • Soft state（软状态）：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性
  • Eventually consistent（最终一致性）：数据最终一定能够达到一致的状态

分布式事务

二阶段事务

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

在二阶段提交算法中，我们需要引入三个假设：

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

在以上三个假设中，二阶段提交算法以如下方式工作：

  1. 协调者作为一个中心节点，负责处理参与者之间可能存在的冲突，参与者负责提交事务并告知协调者。
  2. 当希望提交事务时，会先进入 Prepare 阶段，协调者向参与者发送询问信息，参与者执行事务，但不提交，返回自己当前的状态是否正常。
  3. 当所有参与者返回正常的确认信号后，进入 Commit 阶段，协调者即可通知参与者进行事务的 commit，并收到 Ack 信号确认 commit 完成。

此时，可能出现以下异常情况：

  • 协调者未宕机，但参与者宕机，Prepare 阶段的参与者向协调者返回错误信号；此时协调者将通知所有参与者对已进行的 commit 进行 rollback 操作以保证数据一致。
  • 协调者宕机，但参与者未宕机，此时只需更换新的协调者，然后重新进行二阶段提交即可。
  • 协调者和参与者均宕机，此时由于无法确认状态，需要数据库管理员接入，防止数据库进入不一致的状态。

二阶段提交算法一定程度上解决了分布式事务提交的数据不一致问题，但也存在缺陷：

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

三阶段事务

三阶段提交在二阶段提交的基础上进行了优化，以解决二阶段提交单点故障和阻塞的问题。针对两阶段提交的补充，将两阶段提交中的Prepare阶段，拆成两部分：CanCommit和PreCommit机制。

  • CanCommit阶段：询问是否可以执行；
  • PreCommit阶段：重新确认是否可以执行；
  • DoCommit阶段：向所有人提交事务。

三阶段缓和了两阶段面临的问题，但依然没有解决 

  • 性能问题 
  • 网络分区场景带来的数据一致性问题

在本阶段如果因为协调者或网络问题，导致参与者迟迟不能收到来自协调者的 commit 或 rollback 请求，那么参与者将不会如两阶段提交中那样陷入阻塞，而是等待超时后继续 commit，相对于两阶段提交虽然降低了同步阻塞，但仍然无法完全避免数据的不一致。

MVCC

多版本并发控制（MCC 或 MVCC）是数据库管理系统常用的一种并发控制方法，用于提供对数据库的并发访问，并以编程语言实现事务内存。

  • 版本的选取：使用物理时钟或逻辑时钟

  • 物理时钟：提供TrueTime API，有Master节点维持一个绝对时间，保证各个服务器之间时钟误差控制在ϵ内，通常ϵ<7ms。

  • 逻辑时钟：中心化授时的方式--时间戳预言机（TSO），好处是无需硬件的支持

共识协议

Quorum NWR模型

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

为了保证强一致性，需要保证 W+R>N。
Quorum NWR模型将CAP的选择交给用户，是一种简化版的一致性模型。

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

RAFT协议

  • Leader - 领导者：Leader 负责处理所有的客户端请求，并向Follower同步请求日志，当日志同步到大多数节点上后，通知Follower提交日志
  • Follower - 跟随者：接受并持久化Leader同步的日志，在Leader告知日志可以提交后，提交日志
  • Candidate - 备选者：Leader选举过程中的临时角色。向其他节点发送请求投票信息

Paxos协议

Paxos算法与RAFT算法区别：

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

分布式实践

  • MapReduce
  • 分布式KV
avatar
文章
阅读
粉丝