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

重点内容

分布式概述
1. 什么是分布式
2. Why-How-What
3. 常见的分布式系统
系统模型
1. 故障模型
2. 拜占庭将军问题
3. 共识和一致性
4. 时间和事件顺序
理论基础
1. CAP理论
2. ACID理论
3. BASE理论
分布式事务
1. 两阶段提交
2. 三阶段提交
3. MVCC
共识协议
1. Quorum NWR模型
2. RAFT协议
3. Paxos协议
分布式实践
1. MapReduce
2. 分布式KV

知识点介绍

分布式概述

什么是分布式

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

优势

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

挑战

普遍的节点故障
不可靠的网络
异构的机器与硬件基础
安全

Why-How-What

使用者视角

Why
- 数据爆炸，对存储和计算有大规模运用的述求
- 成本低，构建在廉价服务器之上
How
- 分布式框架
- 成熟的分布式系统
What
- 理清规模，负载，一致性要求等
- 明确稳定性要求，制定技术方案

学习者视角

Why
- 后端开发必备技能
- 帮助理解后台服务器之间协作的机理
How
- 掌握分布式理论
- 了解一致性协议
What
- 把要点深入展开，针对难点搜索互联网资料进行学习
- 把所学知识用于实践

常见的分布式系统

分布式存储

Google File System ( GFS )：google分布式文件系统
Ceph：统一的分布式存储系统
Hadoop HDFS：基于GFSA架构的开源分布式文件系统
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 failure：节点收到数据的时间无限晚，即收不到数据
Crash failure：在omission failure的基础上，增加了节点停止相应的假设，也即持续性地omission failure
Fail-stop failure：在Crash failure的基础上增加了错误可检测的假设（确定的错误码

拜占庭将军问题

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

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

方案一：同时发送N个信使，任何一个到达敌方军队，都算成功。

方案二：设置超时时间，发送后未在一定时间返回，则增加信使。

共识和消息传递不同：即使保证了消息传递成功，也不一定能达成共识

TCP三次握手是在两个方向确认包的序列号，增加了超时重试，是两将军问题的一个工程解。

思考：

为什么是三次握手？而不是两次或四次？
挥手过程中，如果FIN报文丢失，发生什么？

为了实现可靠数据传输， TCP 协议的通信双方，都必须维护一个序列号，以标识发送出去的数据包中，哪些是已经被对方收到的。三次握手的过程即是通信双方相互告知序列号起始值，并确认对方已经收到了序列号起始值的必经步骤。如果只是两次握手，至多只有连接发起方的起始序列号能被确认，另一方选择的序列号则得不到确认。避免浪费资源将服务端向客户端的确认信息和同步信号一起发送，避免浪费资源，因此不是四次握手。
客户端调用close函数时将会发送FIN报文（引用计数减一，引用计数为0时触发TCP挥手关闭TCP连接），如果FIN报文丢失，则客户端会开始重传，当重传次数达到上限时，客户端将会进入CLOSE状态。

共识和一致性

客户端A读到x=0，当客户端C正在写入时，客户端A和B可能读到0或者1 。但是当C写入完成后，A和B最终能读到一致的数据。我们称这样的一致性为Eventually consistent（最终一致性）

当客户端A读到更新后的版本x=1后，及时将消息同步给其他客户端，这样其他客户端立即能获取到x=1 。我们称这样的一致性为Linearizability（线性一致性）。如果要保证“线性一致性”，多个节点间势必需要进行协商，以寻求一致。这样增加了延迟，系统可用性便会增加。

理论基础

CAP理论

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

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

CA：放弃分区容错性，加强一致性和可用性，其实就是传统的单机数据库的选择

AP：放弃一致性（这里属的一致性是强一致性），追求分区容错性和可用性，例如一些注重用户体验的系统

CP：放弃可用性，追求一致性和分区容错性，例如与钱财安全相关的系统

ACID理论

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

数据库事务拥有四个特性ACID，即原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability）。

原子性（A）：事务包含的所有操作要么全部成功，要么全部失败回滚
一致性（C）：事务必须是数据库从一个一致性状态变换另一个一致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态
隔离性（I）：当多个用户并发访问数据库时，数据库为每一个用户开启的事务，不能被其他事务的操作所干扰，多个并发事务之间要相互隔离
持久性（D）：一个事务一旦被提交了，那么对数据库中的数据改变就是永久性的，即使实在数据库系统遇到故障的情况下也不会丢失提交事务的操作

分布式事务

二阶段提交

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

需要注意的问题

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

三阶段提交

将两阶段提交中的Prepare阶段，拆分为两部分：CanCommit和PreCommit机制

解决了两个问题

单点故障
阻塞

MVCC

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

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

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

Quorum NWR模型

Quorum NWR三要素

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

为了保证强一致性，需要保证W+R>N

RAFT协议

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

三种角色

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

Paxos协议

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

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