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

分布式理论

分布式概述

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

优势

去中心化

低成本

弹性

资源共享

可靠性高：多副本冗余存储

挑战

普遍的节点故障

不可靠的网络：需要处理更多的状态

异构的机器与硬件环境：性能不可预测

安全

原因

数据爆炸，对存储和计算有大规模运用的述求

成本低，构建在廉价服务器之上

常见分布式系统

分布式存储

Google File System : google分布式文件系统

Ceph ：统一的分布式存储系统

HadoopHDFS：基于GFS架构的开源分布式文件系统

Zookeeper：高可用的分布式数据管理与系统协调框架

分布式数据库

Google Spanner：Google可扩展的、全球分布式的数据库

TiDB：开源分布式关系型数据库

HBase：开源Nosql数据库

MongoDB：文档数据库

分布式计算

Hadoop：基于MapReduce分布式计算框架

Spark：在Hadoop基础上，使用内存来存储数据

YARN：分布式资源调度

系统模型

故障模型

解决难度从高到低，一般不解决Byzantine

Byzantine failure：节点可以任意篡改发送给其他节点数据

ADB：节点可以篡改数据，但不能伪造其他节点的数据

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或down	Performance，Omission
内核故障	内核内部的致命错误，产生kernel panic	Crash
CPU故障	年故障率接近1%	Omission、Crash
电源故障	服务器失去电力支撑	Omission
软件故障	如：进程crash、内存踩坏、状态不一致、配置错误、软件bug等	Byzantine

拜占庭将军问题

CAP理论

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

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

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

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

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

AP：放弃一致性，例如注重用户体验的系统

CP：放弃可用性，例如与钱财相关的系统

ACID理论

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

原子性（Atomicity）：事务包含的操作要么全部成功，要么全部失败回滚

一致性（Contistency）：事务必须使数据库从一个一致性状态变换到另一个一致性状态。

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

持久性（Durablitiy）：一个事务一旦被提交，那么对数据库中数据的改变是永久的。

BASE理论

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

核心思想

Basically Available（基本可用）：假设系统，出现了不可预知的故障，但还是能用，相比较正常的系统而言：响应时间上的损失，或功能上的损失

Soft state（软状态）：允许系统处于中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。

Eventually consistent（最终一致性）：系统能够保证在没有其他新的更新操作的情况下，数据最终一定能够达到一致的状态。

分布式事务

两阶段提交

三个假设

1、引入协调者和参与者，互相进行网络通信

2、所有节点都采用预写式日志，且日志被写入后即被保持在可靠的存储设备上

3、所有节点不会永久性损失，即时损坏后仍然可以恢复

三阶段提交

解决阻塞问题，通过判断是否可以commit实现

MVCC

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

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

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

在Spanner论文里通过TrueTime API提供一个物理时钟的方式。

另一种方式：时间戳预言机

共识协议

Quorum NWR模型

三要素

N:在分布式存储系统中，有多少份备份数据

W:代表一次成功的更新操作要求至少有w份数据写入成功

R：代表一个成功的读数据操作要求至少有R份数据成功读取

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

RAFT协议

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

三种角色：

Leader，通常一个系统中是一主多从。Leader负责处理所有的客户端请求，并向Follower同步请求日志，当日志同步到大多数节点上后，通知Follower提交日志。

Follower，不会发送任何请求。接受并持久化Leader同步的日志，在Leader报告日志可以提交后，提交日志。当Leader出现故障时，主动推荐自己为Candidate。

Candidate，Leader选举过程中的临时角色。向其他节点发送请求投票信息。如果获得大多数选票则晋升为Leader。

Log（日志）：节点之间同步的信息，以只最佳写的方式同步进行

Term（任期号）：单调递增，每个Term内最多只有一个Leader

Committed：日志被复制到多数派节点，即可认为已经被提交

Leader选举过程：

1、初始全部为Follower

2、Current Term+1

3、选举自己

4、向其他参与者发起RequestVote请求，retry直到

• 收到多数派请求，称为Leader，并发送心跳

• 收到其他Leader请求，转为Follower，更新自己的Term

• 收到部分，但未达到大多数派，选举超时，随机timeout开始下一轮

两个规则

在一个任期内每个参与者最多投一票（持久化）

要称为Leader，必须拿到多数选票

切主

当Leader出现问题时，就需要重新选举

Stale读

解决多主问题，通过等待双倍超时时间

Paxos协议

与Raft算法的区别

可以并发修改日志，而Raft写日志操作必须连续

可以随机选主，不必最新最全的节点为Leader