分布式基础学习｜青训营笔记这是我参与「第五届青训营」伴学笔记创作活动的第 7 天，主要记录相关的知识点。目录分

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

1.分布式概述

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

去中心化
低成本
弹性
资源共享
可靠性高

面临的问题：

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

常见的分布式系统
分布式存储：

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

分布式数据库：

Google Spanner:
TiDB: 开源分布式关系型数据库
HBase ：开源Nosql数据库
MongoDB : 文档数据库

分布式计算：

Hadoop : 基于MapReduce的分步式计算框架
Spark ： Hadoop之上，使用内存来存储数据，速度非常快
YARN ：分布式资源调度

2.系统模型

故障模型

按处理难易程度分类：

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

按模型分类：

磁盘、主板、交换机、网络分区、cpu、内存、线缆、电源等

拜占庭将军问题

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

共识和一致性

由于执行时机不同，不同的客户端读取到的数据是有偏差的，为了保证一致性行为，所有客户端需要达成共识，将更新的数据同步给所有人。
一致性和可用性是对矛盾

3.理论基础

CAP理论

C （Consistence）一致性，指多个数据在多个副本之间能够保持严格一致性
A （Availability）可用性
P （Network partitioning）分区容错性

三者无法同时获得

CP系统：故障发生时，为了避免读到不一致的数据，可能拒绝访问
AP系统：故障发生时，为了保证可用性，允许不同进程读到不同的数据

ACID理论

ACID理论是针对CA系统而言
数据库事务拥有四个特性：
- 原子性（Atomicity）: 要么全部成功，要么全部失败回滚
- 一致性（Consistency）：事务执行前后都必须处于一致性状态
- 隔离性（Isolation）：多个事务不会互相干扰
- 和持久性（Durability）：事务一旦提交，则改变是永久性的。即便故障也不会丢失提交事务的操作

BASE理论

BASE理论是针对AP系统而言的，
- Basically Available(基本可用)：即使系统出现了不可预知的故障，但还是能用
- Soft state（软状态）：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性
- Eventually consistent（最终一致性）：数据最终一定能够达到一致的状态（保证读到的数据都是最新的）

4.分布式事务

二阶段提交

定义：
- 二阶段提交（Two-phase Commit）：为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种演算法。
三个假设：
- 引入协调者和参与者互相进行网络通信
- 所有节点都采用预写式日志且写入后被保持在可靠的存储设备上
- 所有节点不会永久性损坏，即使损坏后仍然可以恢复
两阶段提交需注意的问题：
- 性能问题：需要进行多次网络通信，资源需要等待并且被锁定
- 新协调者：选出新协调者
- 网络分区带来的数据不一致：非所有节点都收到Commit请求，导致节点间数据不一致

三阶段提交

在两阶段提交的基础上，将两阶段提交中的Prepare阶段，拆成两部分：CanCommit和PreCommit机制
解决了单点故障和阻塞问题
CanCommit阶段：询问是否可以执行；PreCommit阶段：重新确认是否可以执行
DoCommit阶段：向所有人提交事务
不过三阶段提交依然没有解决：性能问题和网络分区场景带来的数据一致性问题

MVCC

MVCC：多版本并发控制的方法。维持一个数据的多个版本使读写操作没有冲突。所以既不会阻塞写，也不阻塞读。提高并发性能的同时也解决了脏读的问题。
悲观锁和乐观锁
- 悲观锁：操作数据时直接把数据锁住，直到操作完成后才会释放锁；上锁期间其他人不能修改数据
- 乐观锁：不会上锁，只是在执行更新时判断别人是否修改数据，只有冲突时才放弃操作
解决方案：使用物理时钟或逻辑时钟
- 物理时钟：提供TrueTime API，有Master节点维持一个绝对时间，保证各个服务器之间时钟误差控制在1ms到7ms。
- 逻辑时钟：时间戳预言机（TSO），采用中心化授时的方式，好处是无需硬件的支持，不过会提高网络通信的成本

5.共识协议

Quorum NWR模型

Quorum NWR三要素：
- N：在分布式存储系统中，有多少份备份数据
- W：代表一次成功的更新操作要求至少有w份数据写入成功
- R：代表一次成功的读数据操作要求至少有R份数据成功读取
- 为了保证强一致性，需要保证 W + R > N
Quorum NWR模型将CAP的选择交给用户，是一种简化版的一致性模型

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

RAFT协议

Raft协议是一种分布式一致性算法（共识算法），即使出现部分节点故障，网络延时等情况，也不影响各节点，进而提高系统的整体可用性。Raft是使用较为广泛的分布式协议。

三种角色
- Leader - 领导者：Leader 负责处理所有的客户端请求，并向Follower同步请求日志，当日志同步到大多数节点上后，通知Follower提交日志
- Follower - 跟随者：接受并持久化Leader同步的日志，在Leader告知日志可以提交后，提交日志
- Candidate - 备选者：Leader选举过程中的临时角色。向其他节点发送请求投票信息，zookper中获得半数以上票数即选举成功
Log（日志）：节点之间同步的信息，以只追加写的方式进行同步，解决了数据被覆盖的问题
Term（任期号）：单调递增，每个Term内最多只有一个Leader
Committed：日志被复制到多数派节点，即可认为已经被提交
Applied：日志被应用到本地状态机：执行了log中命令，修改了内存状态
Leader选举过程：
- 初始全部为Follower
- Current Term + 1
- 选举自己
- 向其它参与者发起RequestVote请求，retry直到
  - 收到多数派请求，成为Leader，并发送心跳
  - 收到其它Leader的请求，转为Follower，更新自己的Term
  - 收到部分，但未达到多数派，选举超时，随机timeout开始下一轮
Log Replication过程：
- 新Leader产生，Leader和Follower不同步，Leader强制覆盖Followers的不同步的日志
切主：当Leader出现问题时，就需要进行重新选举
Stale读：发生Leader切换，old leader收到了读请求。如果直接响应，可能会有Stale Read

Paxos协议

Paxos算法与RAFT算法区别：
- Multi-Paxos 可以并发修改日志，而Raft写日志操作必须是连续的
- Multi-Paxos 可以随机选主，不必最新最全的节点当选Leader
- 优势：写入并发性能高，所有节点都能写入
- 劣势：没有一个节点有完整的最新的数据，恢复流程复杂，需要同步历史记录

分布式基础学习 ｜ 青训营笔记

目录