分布式理论(一)｜青训营笔记

路有所思
88 阅读8分钟

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

1. 概述

我将主要介绍如下知识点：

  1. 分布式概述
  2. 系统模型
  3. 理论基础

2. 分布式概述

2.1 什么是分布式

概念：

  • 分布式系统是跨多个节点的计算机程序的集合，可以分为分布式计算、分布式存储、分布式数据库等

优势：

  • 使用分布式系统的五大优势：去中心化、低成本、弹性、资源共享、可靠性高

挑战：

  • 普遍的节点故障、不可靠的网络、异构的机器与硬件环境、安全

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

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

2.2 常见的分布式系统

分布式存储：

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

分布式数据库：

  • Google Spanner：google可扩展的、全球分布式的数据库
  • TiDB：开源分布式关系型数据库
  • HBase：开源Nosql数据库
  • MangoDB：文档数据库

分布式计算：

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

3. 系统模型

3.1 故障模型

六种故障模型，从处理的难易程度分类：

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

3.2 拜占庭将军问题

实际分布式系统中，绝大多数系统都不是一个拜占庭容错的系统

两将军问题：

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

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

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

三将军问题：

拜占庭将军将考虑更加普适的场景，例如 3 个将军 ABC 互相传递消息(票数过半则通过，反之不通过)，消息可能丢失，也可能被篡改，当有一个将军是 ”叛徒“ (即出现拜占庭故障) 时，整个系统无法达成一致

  • 如果没有叛徒，最终总能达成一致的行动

  • 如果有叛徒，假设两个 “忠将” A和B，一个 “叛徒” C，互相传递消息，由于“叛徒”C的存在，将军 A 和将军 B 获得不同的信息。这样将军 A 获得2票进攻1票撤退的信息，将军 B 获得1票进攻2票撤退的信息，产生了不一致

四将军问题：

考虑当有四个将军，只有一个叛徒的场景：

将军D作为消息分发中枢(即D不会进行投票，负责收集和传递意见)，约定如果没收到消息则执行撤退

第一轮让 D 收集和传递大家的投票信息

第二轮让 ABC 互相进行消息传递(第二轮就类似三将军问题)

  • 步骤：

    • 如果D为 “叛徒”，就变成没有叛徒的三将军问题，ABC 无论收到任何消息，总能达成一致

    • D为 “忠将” ，ABC 有2人将 D 的消息进行正确的传递，同样能保证最终决策符合大多数

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

3.3 共识和一致性

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

  • 读请求和写请求并发时可能读到旧值

    • 客户端A读到x=0，当客户端C正在写入(x=1)时，客户端A和B可能读到0或者1

    • 但是当C写入完成后，A和B最终能读到一致的数据，我们称这样的一致性为 Eventually consistent(最终一致性)

  • 一旦某个读获取到新值，所有客户端都必须返回新值

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

    • 若要保证 ”线性“ 一致性(要保证所有客户端看到相同的值)，多个节点间势必要进行“协商”，以寻求一致。但这样势必增加了延迟，系统可用性会受损

结论：一致性和可用性是对矛盾

4. 理论基础

4.1 CAP 理论

定义：

CAP的定义，分别代表、可用性、分区容错性

三者无法同时达到

  • C(Consistence)：一致性，指数据在多个副本之间能够保持一致的特性(严格的一致性)

  • A(Availability)：可用性，指系统提供的服务必须一直处于可用的状态，每次请求都能获取到非错的响应——但是不能保证获取的数据为最新数据

  • P(Network partitioning)：分区容错性，分布式系统在遇到任何网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务，除非整个网络环境都发生了故障

CAP诞生的三类系统：

  • CA系统：传统数据库的代表

  • AP系统：放弃强一致性，保证高可用，不少nosql存储系统采用

  • CP系统：放弃可用性，保证数据一致性，例如与钱财安全相关的系统

举例说明两个分布式进程之间同步数据，当出现故障的时候，如何选择不同的CAP系统，以及带来的影响：

  • AP系统：故障发生时，为了保证可用性，允许不同进程读到不同的数据

  • CP系统：故障发生时，为了避免读到不一致的数据，可能拒绝访问

针对故障场景，可以通过故障转移的方式，做一个相对较优的解决方式：

  • 允许一个进程作为 Master，其他进程作为Backup，当故障时将请求转移给Backup进行处理

4.2 ACID 理论

ACID理论是针对CA系统而言的，通常在数据库中具有广泛意义

事务：

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

数据库事务拥有四个特性ACID：

  • 原子性(Atomicity)

    • 事务包含的所有操作要么全部成功，要么全部失败回滚

  • 一致性(Consistency)

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

  • 隔离性(Isolation)

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

  • 持久性(Durability)

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

4.3 BASE 理论

BASE 理论是针对AP系统而言的，其来源于对大型互联网分布式实践的总结，其核心思想如下：

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

5. 总结

好的分布式系统架构并不是一蹴而就的，而是随着企业和用户的需求不断迭代演进的，之后我会在第二篇里继续介绍分布式事务和共识协议。

参考：

  • 字节内部课：分布式理论 - 现代架构基石
avatar
文章
阅读
粉丝