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

前言

本文主要记录笔者对于分布式理论课程的学习，主要从分布式概述、系统模型、理论基础、分布式事务这几部分详细学习分布式理论。

分布式概述

什么是分布式

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

优势

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

挑战

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

why-how-what

	使用者视角	学习者视角
why	1.数据操作、对存储和计算有大规模运用的需求。2.成本低，构建在廉价服务器上。	1.后端开发必备技能。2.帮助理解后台服务器之间的协作的机理。
how	1.分布式框架。2.成熟的分布式系统。	1.掌握分布式理论。2.了解一致性协议。
what	1.理清规模、负载、一致性要求等。2.明确稳定性要求，制定技术方案。	1.把要点深入展开，针对难点搜索互联网资料进行学习。2.将所学知识运用于实践。

常见的分布式系统

分布式存储

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

分布式数据库

• Google Spanner：Google可扩展的、全球分布式的数据库。
• TIDB：开源分布式关系型数据库。
• Hbase：开眼Nosql数据库。
• MongoDB：文档数据库。

分布式计算

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

系统模型

故障模型

• Byzanitne failure：节点可以任意篡改发送给其他节点的数据。
• Authentication detectable byzantine failure（ADB）：Byzanitne failure特例：节点可以篡改数据，但不能伪造其他节点的数据。
• Performance failure：节点未在特定时间内收到数据，即时间太早或太晚。
• Omission failure：节点收到数据的时间无限晚，即收不到数据。
• Crash failure：在omission failure的基础上，增加了节点停止响应的假设，也即持续性的omisssion failure。
• Fail-stop failure：在Crash failure的继承上增加了错误可检测的假设。

故障模型
故障	描述	可能类型
磁盘故障	磁头不寻道、盘片不转、磁介质损伤等	Daik-stop
磁盘坏道、坏块	磁头划伤引起坏道，或受宇宙射线影响晶体管产生位反转	Fail-stop,ADB
服务器主板、板卡故障	可能是风扇故障，或灰尘引起的短路，或SCSI/RAID卡造成的死机	Crash
网络故障	电源故障、背板故障等，网卡位反转、网络流量太大造成大量丢包等	Byzantine,Omission
网络分区	网络引起节点形成不同的子集，子集中网络相通，子集间网络不通	Perfoemance
内存故障	内存出错造成的数据被篡改，分为UE、CE两种	ADB
线缆故障	服务器光模块频繁up或down	Performance,Omssion
内核崩溃	内核内部致命错误，产生的kernel panic	Crash
CPU故障	年故障率近1%	Omssion,Crash
电源故障	服务器失去电力支撑	Omssion
软件故障	进程carsb、内存踩坏、状态不一致、配置错误、软件bug等	Byzantine,Crash等

共识性和一致性

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

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

2.当客户端A读到更新的版本X=1后，及时将消息同步给其他客户端，这样其他客户端立即能获取到X=1.称这样的一致性为Linearizability（线性一致性）。

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

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

时间和事件顺序

我们定义“happend before”关系，记为“->”，满足以下三个条件：

1.如果a和b是在相同节点上的两个事件，a在b之前发生，则定义：a->b。

2.如果事件a表示某个节点发送某条消息，b是另一个节点接收这条消息，则有a->b。

3.如果有a->b且b->c,则有a->c。

当且仅当a->/b且b->/a时，称两个事件为并发的（concurrent）。

在图中我们很容易找到若干满足条件的事件对，例如p1->r4,由p1->q2->q4->r3->r4推导来的。

Lamport逻辑时钟

对于每一个节点Pi我们定义一个时钟Ci为一个函数，它为任意的事件a赋值编号为Ci(a)。

1.如果a和b是在相同节点Pi上的两个事件，a在b之前发生，则有Ci(a)<Ci(b)。

2.如果事件a表示节点Pi发送某条消息，b表示节点Pj接收这条消息，则有Ci(a)<Cj(b)。

于是我们可以在时空图中加入类似下图虚线所示的“tick line”。在同一节点内的连续两个事件之间至少要有一条tick line，利用这种逻辑时钟，我们可以对整个系统中的事件进行全序排序。

理论基础

CAP理论

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

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

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

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

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

在网络发生分区的情况下，必须在可用性和一致性之间做出选择，近似解决办法：把故障节点的负载转移给备用节点负载。

ACID理论

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

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

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

BASE理论

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

• Basically Availabel（基本可用）:假设系统出现了不可预知的故障，但还能用（相比正向系统而言，响应时间上或功能上的损失）。
• Soft state（软状态）：允许系统中的数据存在中间状态，并认为该状态不影响系统可用性，即允许系统在多个不同节点的数据副本存在数据延时。
• Eventually consistent（最终一致性）：系统能够保证没有其他更新操作的情况下，数据最终能够达到一致的状态。

分布式事务

二阶段提交

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

三个假设

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

可能出现的情况

• 1.Coordinator不宕机，Participant宕机，需要进行回滚操作。
• 2.Coordinator宕机，Participant不宕机，可以起新的协调者，待查询状态后重复二阶段提交。
• 3.Coordinator宕机，Participant宕机，无法确认状态，需要数据库管理员介入，防止数据库进入下一个不一致的状态。

回滚：在Prepare阶段，如果某个事务参与者反馈消息失败，说明该节点的本地事务执行失败，必须回滚。

需要注意的问题

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

三阶段提交

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

• 1.询问是否可以执行CanCommit，可以则进入PreCommit阶段（失败或者超时则退出）。
• 2.询问是否可以执行PreCommit，可以则进入DoCommit阶段（失败或超时则Rollback）。
• 3.向所有人提交事务请求DoCommit，反馈提交结果Ack。

解决了两个问题（单点故障问题，阻塞问题），引入超时机制，在等待超时后会继续进行事务的提交。

MVCC

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

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

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

小结

对分布式的有了一个大概的了解，且里面的一些设计方法、理论、思想能够极大的帮助我在平时对于其他技术栈的学习。

参考

• 字节跳动青训营《分布式理论-现代架构基石》课程