《分布式系统》期末复习总结

UpCmT

已于 2023-12-06 21:30:07 修改

阅读量450

点赞数 2

分类专栏：课程复习汇总文章标签：课程设计

于 2023-11-17 14:24:11 首次发布

本文链接：https://blog.csdn.net/weixin_53042232/article/details/134462211

版权

课程复习汇总专栏收录该内容

2 篇文章 0 订阅

订阅专栏

第一章：介绍

1.分布式系统的构建原因。

为了功能分离、为了满足计算机固有的分布性、为了使负载均衡、为了可靠性 、为了经济性。

2.分布式系统的定义、特征。

什么是分布式系统：分布式系统是位于网络计算机上的组件仅通过传递消息进行通信和协调其动作的系统。

分布式系统的目标：实现资源共享和协同计算。

分布式系统的三个基本特点：

并发性：多个程序并发执行，共享资源。

无全局时钟：每个机器有各自的时间，难以精确同步，程序间的协调靠交换消息。

故障独立性：一些进程出现故障，并不能保证其他进程都能知道。

3.分布式系统的举例。

3.1、web搜索：Google，最大最复杂的分布式系统之一。

3.2、大型多人在线游戏：

3.3、金融交易

3.4、区块链系统

3.5、语音系统

3.6、数据库系统

4.分布式系统面临的挑战。

异构性：网络协议不同，使用硬件不同，操作系统不同，编程语言不同、开发者实现的方式不同。都造成了一个机器与另一个机器之间交互的困难。（使用中间件和移动代码（虚拟机）来缓解问题）

开放性：一个系统是否可以扩充或者以不同的方式重新实现。在多大程度上新的资源共享服务可以加到系统中来。 关键就是要有公开接口（API）。

安全性：机密性：防止未经授权的个人访问资源。完整性：防止数据被篡改和破坏。可用性：防止对所提供服务的干扰。

可伸缩性：系统扩展到一定规模后，无论是资源还是用户，系统的性能要保持在一定水平。

故障处理：检测故障：分布式系统确切知道远程服务器是否出现故障是十分困难的。

屏蔽故障：重发没有收到的消息，备份服务器。

故障容错：让用户知道出现了问题，用户可以自由选择是否继续请求服务。

故障恢复：操作日志、恢复

冗余策略

并发：正确性：多个进程访问共享资源，要保证被访问资源的正确性。

性能：保证系统能够支持多个并发操作

透明性：访问透明：使用同样的操作去访问本地和远程资源。

位置透明：访问资源的时候，不需要知道资源的具体位置。

并发透明：几个进程同时访问资源，互不干扰

第二章：系统模型

物理模型：考虑组成系统的计算机和设备的类型以及它们的互连，不涉及特定的技术细节。

体系结构模型：从系统的计算元素执行的计算和通信任务方面来描述系统。

基础模型：采用抽象的观点描述大多数分布式系统面临的单个问题方案。

1.分布式系统的物理模型。

从计算机和所用网络技术的特定细节中抽象出来的分布式系统底层硬件元素的表示。

2.分布式系统体系结构模型。

2.1、C/S，P2P两种不同结构

C/S:

P2P:

2.2、分层模型、层次化模型

分层模型：一个复杂的系统被分成若干层，每层利用下层提供的服务。

中间件层：中间件是一种软件，它提供基本的通信模块和其他一些基础服务模块，为应用程序开发提供平台。

层次化模型：

3.交互、故障、安全三种基础模型

交互模型：延迟的不确定性及缺乏全局时钟的影响。

故障模型：组件、网络等故障的定义、分类。

安全模型：内、外部攻击定义、分类。

交互模型：分布式系统由多个以复杂方式进行交互的进程组成。进程之间通过消息传递进行交互，实现系统的通信和协作功能。

两个影响进程交互的因素：1、通信性能。2、难以维护的全局时钟。

通信信道的性能：延迟：第一个比特流从发出到到达目的节点在网络中所花费的时间、访问网络的时间、操作系统通信服务的时间。

带宽：在单位时间内，网络上能够传输的信息的总量。

抖动：传输一系列信息所花费时间的变化值。例如抖动会影响流媒体服务的质量，因为这类数据要求相对稳定的传输率。

难以维护的全局时钟：每台计算机具有自己的独立内部时钟。计算机时钟和绝对时间存在偏移。

故障模型：计算机或者网络的故障，会影响服务的正确性。故障模型的意义在于将定义可能出现的故障形式，为分析故障带来的影响提供依据。包括遗漏故障，随机故障，时序故障。

遗漏故障：进程或者通信信道没有正常的工作。

进程遗漏故障：进程崩溃。通信遗漏故障：丢失信息。

丢失故障是良性故障。

随机故障（拜占庭故障）：对系统影响很大的一种故障形式，而且错误很难探知。

发生在进程中的随机故障：随便遗漏应有的处理步骤或进行不应有的处理步骤，该做的不做，不该做的却做了。

随机故障很少出现在通信信道。

时序故障：仅仅发生在同步分布式系统中。异步系统无时间保证，故不存在此类故障。

屏蔽故障：分布式系统中的每个组件通常基于其他一组组件构造，利用存在故障的组件构造可靠的服务是可能的。

安全模型：分布式系统的模块特性以及开放性，使得它们暴露在内部和外部的攻击之下。安全模型的目的是提供依据，以此分析系统可能受到的侵害，并在设计系统时防止这些侵害的发生。

分布式系统的安全性：进程的安全性、通信信道的安全性、对象的安全性。

保护对象的措施：访问权限、权能。

安全模型的威胁：

对进程的威胁：对服务器：来自一个伪造实体的调用请求，例如CSRF。

对客户端：收到一个伪造的结果（钓鱼），例如：窃取密码。

对信道的威胁：拷贝消息，篡改或者填充。保存并重发。

DOS攻击：发出大量的服务请求。

移动代码：恶意代码入侵系统，例如：特洛伊木马。

安全模型的对策：

加密技术和共享密钥：通过共享密钥相互确认对方。

认证：对发送方提供确认身份进行认证。

安全通道：每个进程知道正在执行的进程所代表的委托方身份。确保在其上传输的数据的私密性和完整性。每个消息包含物理的和逻辑的时间戳。

4.同步、异步两种不同的分布式系统

根据是否对时间有严格的假设限制，可以得到两个变体：

同步分布式系统：有严格的时间限制假设。

异步分布式系统：无严格的时间限制假设，非常常见。

同步分布式系统：

进程执行每一步的时间有一个上限和下限。

每个在网络上传输消息可在已知时间范围内接收到。

每个进程的局部时钟相对于实际时间的漂移在已知的范围内。

异步分布式系统——没有可预测的时限：

进程执行速度：每一步都可能需要任意长时间。

消息传递延迟：收到一个消息的等待时间可能任意长。

时钟漂移率：漂移率可能是任意的。

第三章：时间和全局状态

3.1、事件、进程历史概念

事件：一个通信动作或进程状态转换动作。

进程历史：在进程中发生的一系列事件，按发生在先排序，即：

3.2、时钟漂移及产生原因

时钟漂移：震荡频率的变化。

产生原因：电源稳定性、环境温度等。

3.3、内部、外部物理时钟同步

内部同步物理时钟：1、无外部权威时间源，系统内时钟同步。2、时钟Ci在范围D内是准确的。

外部同步物理时钟：1、采用权威的外部时间源。2、时钟Ci在范围D内是准确的。

二者之间的关系：若P（时钟集合）在范围D内外部同步，则P在范围2D内内部同步。

3.4、时钟正确性的含义

时钟正确性：

1、基于漂移率——漂移率在一个已知的范围内：

2、基于单调性：

3、基于混合条件：单调性+漂移率有界+同步点跳跃前进。

3.5、物理时钟同步的三种方法

3.5.1、Cristian方法：

应用条件：1、存在时间服务器，作为外部时钟源。

2、消息往返时间与系统所要求的精度相比足够短。

协议：1、进程p根据消息mr，mt计算消息往返时间T

2、根据服务器在mt中放置的时间t设置时钟为：t+T/2.

精度分析：若消息的最小传输时间为min，则精度为：±（T/2-min）。

此处t为消息发送时刻。

理想状况：T=2*min->误差为0。（理想系统处理时延为0，只考虑传输时延）

3.5.2、Berkeley算法

计算方法：1、主机周期轮询从属机时间。

2、主机通过消息往返时间估算从属机时间（与Cristian方法类似）

3、主机计算容错平均值

4、主机发送每个从属机的调整量

3.5.3、网络时间协议（Network Time Protocol，NTP）

优势：1、可外部同步：使得跨Internet的用户能精确的与UTC（通用协调时间）同步。

2、高度可靠性：可处理连接丢失，采用冗余服务器、路径等。

3、扩展性好：大量用户可经常同步，以抵消漂移率的影响。

4、安全性强：防止恶意或偶然的干扰。

协议结构：1、层次结构——strata

2、主服务器直接与外部UTC同步

3、同步子网可重新配置

同步模式：

1、组播模式：适用于告诉LAN；准确度较低，但效率高。

2、服务器/客户端模式：与Cristian算法类似；准确度高于组播。

3、对称模式：保留时序信息；准确度最高。

3.6、逻辑时间、逻辑时钟

为什么引入逻辑时间？：1、节点具有独立时钟，缺乏全局时钟。后发生的事件有可能赋予较早的时间标记。2、由于消息传输延迟的不确定性，分布式系统中的物理时钟没法完全同步。3、事件排序是众多分布式算法（互斥算法，死锁检测算法）的基石。

逻辑时钟：众多应用只要求所有节点具有相同的时间基准，该时间不一定与物理时间相同。因为不进行交互的两个进程之间不需要时间同步，只需在事件的发生顺序上达成一致。

3.7、发生在先关系、并发关系及分布式系统中的事件排序

发生在先关系：1、若进程pi满足e ->i e',则e->e'。即若进程e发送消息在e‘接收消息之前，那么就可以认为由e推出e'。

2、对于任一消息m，存在send(m)->recv(m)

3、若事件满足e->e',e'->e''，那么可以认为e->e''。即若e发生在e'之前，e'发生在e'’之前，那么就可以认为e发生在e'‘之前。

并发关系：X||Y:X->Y与Y->X均不成立，则称事件X和Y是并发的。

3.8、lamport时钟、全序逻辑时钟及向量时钟

Lamport时钟机制：1、进程维护一个单调递增的软件计数器，充当逻辑时钟。2、用逻辑时钟为事件添加时间戳。3、按事件的时间戳大小为事件排序。

逻辑时钟修改规则：进程pi执行事件之前，逻辑时钟Li=Li+1。当进程pi发送消息m时，在m中添加时间戳t=Li。进程pj在接收（m，t）时，更新Lj=max（Lj，t+1）。并给事件recv(m)添加时间戳为更新后的Lj。例如：

全序逻辑时钟：使用（时间戳，进程号）这个二元组描述进程中各事件的发生关系。如果e,e'分别为进程Pi和Pj中发生的事件，则其全局逻辑时间戳分别为（Ti，i），（Tj，j）。且有e->e'。那么可以得到：Ti<=Tj or （Ti=Tj&&i<j）。

全序逻辑时钟下，各事件的Lamport时间戳均不相同。

向量时钟：克服了Lamport时钟的缺点：L(e)<L(e')不能推出e->e'。

每个向量都会维护自己的向量时钟，即n元组，n位表示出n个进程的逻辑时钟。每次进行事件时会给对应自己的那一位+1。即执行Vi[i]=Vi[i]+1。其他位的时钟取最大值。例如：

物理意义：观察到的对应进程的最新状态可以包含全局信息。

而Lamport时钟只有部分全局信息。

3.9、割集、割集的一致性、一致的全局状态概念

割集：系统全局历史的子集。，对应记录每个进程执行到了哪个事件。比如1进程执行到了c1事件。

割集的一致性：指对于所有事件e∈C，都有f->e，可以推出f∈C。即发生在e之前的事件也要在割集里面。

一致的全局状态：对应于一致的割集状态。

走向（Run）：往前走一步（可能有多种选择）形成事件的序列（状态的变化）->系统的一种可能得执行过程。比如：S0->S1->S2->S3

走向是指全局历史中所有事件的全序，与每个本地历史顺序一致，并不是所有的走向都经历一致的全局状态。例如：.这就没有都经历一致的全局状态。

、

线性化（一致性）走向：所有的线性化走向只经历一致的全局状态。若存在一个经过S和S'的线性化走向，则状态S'是从S可达。

3.10、chandy-lamport快照算法

目的：捕获一致的全局状态

假设：进程和通道均不会出现故障。单向通道，提供FIFO顺序的消息传递。进程之间存在强联通关系。

任一进程可在任一时间开始全局拍照。

拍照时，进程可继续执行，并发送和接受消息。

拍照算法：1、首次接受标记，会把标记发送方到自己的通道置为空。因为FIFO的假设，标记后的消息不作数。接受标记后，向其他所有通道发送一个标记。

2、如果不是首次接受标记。就会把标记发送方到自己的通道中的所有消息记录下来。

第四章、协调和协定

4.1、分布式互斥的含义

目的：仅基于消息投递，实现对资源的互斥访问。

假设：异步系统；无故障进程；可靠的消息投递。

基本要求：安全性：在临界区内一次最多有一个进程可以执行。

活性：进入和离开临界区的请求最终成功执行。

顺序：进入临界区的顺序和进入请求的happen-before顺序一致。（第二个操作发生前能够看到第一个操作的执行结果）

性能评价：带宽消耗：在每个enter和exit操作中发送的消息数。

客户延迟：进程进入、退出临界区的等待时间。

吞吐率：单位时间纯切换CS的速度。

4.2、解决分布式互斥的方法：中央服务器、环、组播+逻辑时钟、Meakawa投票算法。

中央服务器算法：满足安全性和活性要求，但不满足顺序要求。

性能：带宽消耗：enter：2个消息，即请求消息+授权消息

exit：1个消息，即释放消息。

客户延迟：enter：request+grant = 1round-trip

exit：release

同步延迟：1个消息的往返时间：1realse+1grant

基于环的算法：满足安全性和活性要求，不满足顺序要求。（循环发送令牌）

性能：带宽消耗：由于令牌的投递，会持续消耗带宽。

客户延迟：Min：0个消息，正好受到令牌。Max：N个消息，正好错过令牌。

同步延迟：Min：1个消息，进程依次进入临界区。Max：N个消息，一个进程持续进入临界区，期间无其他进程进入临界区。

基于组播和逻辑时钟的算法：满足安全性、活性和顺序性

进程进入临界区需要所有其他进程同意（组播+应答）

并发控制：采用Lamport clock避免死锁（全序关系）

性能：带宽消耗：enter：2(N-1)，即N-1个请求、N-1个应答。（要其他进程同意）

客户延迟：1round-trip

同步延迟：1个消息的传输时间

Maekawa投票算法：改进后可满足安全性、顺序性和活性

进程进入临界区不需要所有进程同意。（部分同意即可）只需得到一个进程子集S中的所有进程的回答即可进入临界区。称子集S是进程P的请求子集。假设Ri和Rj分别是进程Pi和Pj的请求子集，要求Ri∩Rj≠NULL。

当进程Pi请求进入临界区时，它只向Ri中的进程发送请求报文。

Maekawa算法会产生死锁：如果进程p1，p2，p3，且V1={p1，p2}，V2={p2，p3}，V3={p3，p1}。若三个进程并发请求进入临界区，分别应答了自己，但无法得到另一个vote。

Maekawa算法改进后可以满足安全性、活性和顺序性。

4.3、分布式选举含义

选举算法：选择一个唯一的进程来扮演特定角色的算法。

召集选举：一个进程启动了选举算法的一次运行。

参与者：进程参与了选举算法的某次运行。

非参与者：进程当前没有参加任何选举算法。

进程标识符：唯一且可按全序排列的任何数值。

基本要求：安全性、活性。

4.4、解决分布式选举的方法：环、霸道

基于环的选举算法：目的：在异步系统中选举具有最大标识符的进程作为协调者。

基本思想：按逻辑环排列一组进程，id不必有序。

算法流程：1、初始化，把每个进程都标记为非参与者。

2、任何进程开启一次选举过程。将自身标记为参与者。并把自身进程id号放入elect消息中向下传播选举消息。

3、收到选举消息时，i)、如果自身id小于选举消息中的id，仅把自己标记为参与者，并向下传播选举消息。 ii)、如果自身id大于选举消息中的id，如果当前进程已是参与者则什么都不做。如果当前进程不是参与者，那么把自己标记为参与者，并把选举消息中的待选举id改成自己的id，向下传播选举消息。 iii)、如果自身id等于选举消息中的id，结束选举过程。这说明选举消息已经转了一圈，没有比自己进程id号大的进程。当前进程就成为协调者。向下发送协调者消息，告知其他进程协调者id。

环选举算法性能最坏需要3N-1个消息，最好需要2N个消息才能完成选举。

不具备容错功能。(某个节点故障会导致选举失败)

霸道算法：同步系统，使用超时检测进程故障。通道可靠，允许进程崩溃。每个进程知道哪些进程具有更大标识符。每个进程均可以和所有其他进程通信。

算法流程：任意进程发现故障就召集选举。i)、当前进程是最大id进程，就发送协调者消息。 ii)、当前进程不是最大id进程，则发送选举消息至具有更大id的进程。如果当前进程没有收到回复消息，说明更大的进程都故障了，自己就是当前最大进程，给所有具有较小标识符的进程发送协调者消息。如果收到回复消息了，就等待更大id号的进程发送协调者消息。若等待超时就发动下一次选举。

进程接收到election消息（只有id号大的进程会接收到id号小的进程发送的election消息），就回复应答消息。或开启另一次选举（同上一步）。

进程记录下来收到的协调者id号。

4.5、基本组播、可靠组播的区别

基本组播：原语：B-multicast、B-deliver

B-multicast(g,m)：对每个进程p∈g，send(p,m)；发送消息给组内其他进程。

B-deliver(m)：传递由组播发送的消息到调用进程，到应用层。

进程p receive(m)时：p执行B-deliver(m)。

可靠组播：完整性：一个正确的进程p投递一个消息m至多一次。

有效性：如果一个正确的进程组播消息m，那么它终将投递m。

协定：如果一个正确的进程投递消息m，那么group中其它正确的进程终将投递m。

与基本组播的区别:B-multicast不保证协定。（sender中途失效）

4.6、实现可靠组播的方法

用B-multicast实现可靠组播：简单思路：当进程p给组g进行组播消息，组g中的进程q接收到组播消息m后会进行如下操作：i)、如果消息m之前接受过，不做处理。ii)、如果没接收过消息m，就把消息m记录下来，并对组g进行一次组播。最后投递消息m。

如果sender（进程p）发送中途失效，只要有一个正确的进程接收了消息m，就会对组内其他正确的进程进行组播，从而保证了协定。

算法满足：完整性、有效性、遵循协定。

但是效率低，每个消息会被一个进程发送|g|次，一共|g|²次。

用IP组播实现可靠组播：将IP组播、捎带确认法和否定确认相结合。

组g中的每个进程p维护的信息：

Sg.p：下一个要发送的消息的序号

Rg.q：来自进程q的最新消息的序号

p要R-multicast一个消息到组g：

捎带Sg.p和确认（即<q,Rg.q>）

Sg.p = Sg.p + 1。

收到一个来自p的广播消息m，准备R-deliver：

1、当且仅当m.S=Rg.p+1,投递消息Rg.p=Rg.p+1。

2、若m.S<=Rg.p,则该消息已经投递。

3、若m.S>Rg.p+1或对任意捎带过来的确认<q,Rg>有Rg>Rg.q，则漏掉了一个或多个消息。或将消息暂存在保留队列中，并发送否认确认NACK，要求重新发送丢失信息。

有序组播：

FIFO组播：如果一个正确的进程发出multicast(g,m)，然后发出multicast(g,m')，那么每个投递m'的正确的进程将在m'前投递m。（先发的消息先投递）

保证每个进程发送的消息在其它进程中的接受顺序一致。

算法流程：与基于IP组播的可靠组播类似，即采用Sgp、Rgq和保留队列。

因果排序：如果multicast(g,m)->multicast(g,m')，那么任何投递m'的正确进程将在m'前投递m。

算法：每个进程维护自己的向量时钟。

全排序：如果一个正确的进程在投递m'前投递消息m，那么其他投递m'的正确进程将在m'前投递m。

全排序算法：

4.7、共识、交互一致性及拜占庭将军问题含义

共识：一个或多个进程提议一个值后，使进程对这个值达成一致意见。

交互一致性：每个进程提议一个值，就向量达成一致。

决定向量：向量中的每个分量与一个进程的值相对应。

算法要求：终止性：每个正确进程最终设置它的决定变量。

协定性：所有正确进程的决定值都相同。

完整性：如果进程pi是正确的，那么所有正确的进程都把vi当作他们决定向量中的第i个分量。

拜占庭将军问题：3个或更多将军协商是进攻还是撤退

1个将军（司令）发布命令，其他将军（中尉）共同决定进攻或撤退。

一个或多个将军可能叛变，所有未叛变的将军执行相同的命令。

与共识问题的区别：拜占庭式一个独立的进程提供一个值，其他进程决定是否采用。

而共识问题是每个进程都会提供一个值，协商达成一致意见。

算法要求：终止性：每个正确进程最终设置它的决定变量。

协定性：所有正确进程的决定值都相同。

完整性：若司令正确，则所有进程采用司令提议的值。

4.8、三个、四个拜占庭将军问题

三个拜占庭将军：三个将军（其中有一个司令），没法达成一致的共识（在有叛变将军存在的情况下）。

由图，根据完整性（听司令的），p2和p3的决定向量不能给出一个决定值（majority函数大多数）。因此三个拜占庭将军是不可能达成协定的。但是4个拜占庭将军可以。

假设：N个进程中最多有f个进程会故障，那么只要N≥3*f+1就可以让正确的进程满足上述3个性质。这是因为：最好的情况下，只要N-f个消息，正确的进程就可以确定决定值（N-f个进程都是正确的）。但是这当中可能会存在故障进程，最坏的情况是N-f个中存在f个故障进程。由于进程使用majority函数确定决定值，因此只需要N-f个进程中，正确的进程数量大于故障进程数量即可。因此需要满足：N-f-f＞f。因此N≥3*f+1。所以四个拜占庭将军就可以达成协定。

四个拜占庭将军问题：正确的将军通过两轮消息达成一致：1、司令给每个将军发送一个值。2、每个将军将收到的值发送给其他将军。3、最后每个将军执行majority函数确定决定值。

左边正常将军有相同的决定值，右边正常的将军也有相同的决定（司令叛变）。

第五章、事物和并发控制

5.1、串行等价的概念、充要条件及应用

串行等价：如果并发事务交错执行的效果等同于按某种次序一次执行一个事务的效果，那么这种交错执行是一种串行等价的交错执行。

使用串行等价作为并发执行的判断标准可以防止更新丢失和不一致检索的问题。

冲突操作：如果两个操作的执行效果和他们的执行次序相关，称这两个操作相互冲突。冲突操作有（对同一个对象进行的操作，不同对象之间的操作不冲突）：read-write，write-write。

两个串行等价的充分必要条件：两个事务中所有的冲突操作都按相同的次序在它们访问的对象上进行。（都是先T后U 或先U后T）

应用：1、判断是否串行等价。2、修改顺序，使得两个事务串行等价。

5.2、事务的三种基本控制方法：锁、乐观方法、时间戳，它们的原理、实现、比较。

并发控制：并发控制协议都是基于串行等价的标准，源于用来解决操作冲突的规则。

包括：锁、乐观并发控制、时间戳排序。

5.2.1、锁：

互斥锁是一种简单的事务串行化实现机制。事务访问对象前请求加锁，若对象已被其他事务锁住，则请求被挂起，直至对象被解锁。

两阶段加锁：为了保证两个事务的所有冲突操作必须以相同的次序执行，事务在释放任何一个锁后，都不允许再申请新的锁。

在第一个阶段，事务不断地获取新的锁。

在第二个阶段，事务释放它的锁。

目的是防止不一致检索和更新丢失的问题。

严格的两阶段加锁：所有在事务执行过程中获取的新锁必须在事务提交或放弃后才能释放。

为了保证可恢复性，锁必须在所有被更新的对象写入持久存储后才能释放。

目的是防止事务放弃导致的脏数据读取和过早写入问题。

读锁和写锁（多个读一个写的机制）：支持多个并发事务同时读取某个对象（不同事务对同一对象的read操作不冲突）。只允许一个事务写对象（write操作前给对象加锁）。

事务的读写操作冲突规则：

死锁：死锁是一种状态，在该状态下一组事务中的每一个事务都在等待其他事务释放某个锁。 等待图：

预防死锁：每个事务在开始运行时锁住它要访问的所有对象。但是这会造成不必要的资源访问限制。减少并发度。

死锁检测：维护等待图，检测图中是否出现环路，如果出现环路就选择环路中的一个事务放弃。

锁超时：解除死锁最常用的方法之一。每个锁都有一个时间期限，超过时间期限的锁成为可剥夺锁。意味着占有可剥夺锁对象的事务可能会被其他请求打断。导致长时间运行的事务被经常放弃。

锁的维护开销大，会引起死锁，并发度低。

5.2.2、乐观并发控制

乐观策略：基于事实：在大多数应用中，两个客户事务访问同一个对象的可能性很低。

方法：访问对象时不作检查操作，事务提交时检测冲突，若存在冲突，则放弃一些事务。

事务的三个阶段：

工作阶段：拥有所修改对象的临时版本。每个事务维护访问对象的读集合和写集合。

验证阶段：事务在收到closeTransaction请求时，判断与其他事务是否存在冲突。

更新阶段：只读事务通过验证立即提交，写事务在对象的临时版本记录到持久存储器后提交。

事务的验证：通过读-写冲突规则确保某个事务的执行对其他重叠事务而言是串行等价的。每个事务在进入验证前会被赋予一个事务号。事务按事务号顺序进入验证阶段。每次仅允许一个事务处于验证和更新阶段。

向后验证：

向前验证：

5.2.3、时间戳排序

事务中的每个操作在执行前先进行验证。

时间戳：每个事务在启动时会被赋予唯一的时间戳，表明该事务在时间序列中的位置。

冲突规则：写请求有效：对象最后一次读访问或写访问由一个较早的事务执行。

读请求有效：对象的最后一次写访问由较早的事务进行。

操作冲突（比较时间戳大小，请求的操作应该最后发生）：

时间戳排序的写规则：

时间戳排序的读规则：

第六章、分布式事务

6.1、分布式事务的概念、平面事务与嵌套事务的概念及区别

分布式事务：访问由多个服务器管理的对象（对象在多个服务器上进行值的更新）的平面事务或嵌套事务。

平面事务：客户给多个服务器发送请求时，执行完了一个请求才会执行下一个请求。顺序访问。

嵌套事务：顶层事务可以创建子事务，子事务也可以进一步以任意深度嵌套子事务。同一层的子事务可以并发执行。（类似于多进程）

6.2、原子提交协议的概念

事务的“原子特性”要求所有参与该事务的服务器必须全部提交或全部放弃该事务。

原子提交协议：允许服务器之间相互通信，以便共同决定是提交还是放弃事务。

要么所有节点必须提交，或所有节点放弃。如果任一节点崩溃，则所有节点必须放弃。

6.3、单阶段原子提交协议原理及缺陷

单阶段原子提交协议：协调者不断向所有参与者发出commit或abort请求，直到所有参与者都确认了commit或者abort。

缺陷：不允许参与者单独决定放弃事务。

可能有一些并发控制问题会阻止参与者提交，协调者可能不知道这种变化。比如为了解除死锁需要放弃任务；乐观并发控制验证失败导致放弃事务；参与者可能崩溃需要放弃事务。

6.4、两阶段提交协议（设计动机、基本思想、基本操作、过程描述、通信、性能、缺陷）

设计动机：允许任意一个参与者自行放弃他自己的那部分事务。

基本思想：一个协调者、多个参与者共同完成一个事务的提交。

分两个阶段完成事务提交。1、在第一阶段，协调者询问所有参与者是否准备好提交。2、在第二阶段，协调者通知所有参与者提交或放弃事务。

基本操作：

过程描述：

阶段1（投票阶段）：

1）、协调者向分布式事务参与者发送canCommit？请求。

2）、参与者收到canCommit？请求后，向协调者回复它的投票（Yes or No）。在投yes票之前，它将在持久性存储中保存所有对象，准备提交。如果投No，参与者立即放弃。

阶段2（根据投票结果完成事务）：

3）、协调者收集所有的投票（包括它自己的投票）

a）、若不存在故障，且所有投票结果均是yes，则协调者决定提交事务，并向所有参与者发送doCommit请求。

b）、否则协调者决定放弃事务，并向所有投yes票的参与者发送doAbort请求。

4）、投yes票的参与者等待协调者发送的doCommit或doAbort请求。一旦参与者收到任何一种请求消息，它根据该请求放弃或者提交事务。如果结果是提交事务，参与者还要向协调者发送一个haveCommitted来确认事务已经提交。

通信：

性能——N个参与者：无服务器崩溃、通信异常的情况下：N个canCommit？消息+N个应答+N个doCommit消息。没有haveCommitted仍能正确运行，故不计算在内。

最坏情况下，可能出现任意多次服务器和通信异常。

可能造成参与者长时间处于“不确定”状态。

缺陷：同步阻塞：在投票yes与docommit之间，所有参与者均处于阻塞状态，无法进行其他任何操作。更甚者，若协调者在发起提议后崩溃，那么投yes票的参与者阻塞至协调者恢复后发送决议。

单点故障：协调者存在性能瓶颈及单点失效的问题。

数据不一致：在协调者发送docommit后，若发生了局部网络异常或者协调者在尚未完全发送docommit前发生了崩溃，就会导致部分参与者接收到了docommit，从而提交事务。而未接收到消息的参与者就不会提交事务，从而导致了数据不一致。

6.5、分布式事务的并发控制（锁、时间戳、乐观方法）

分布式事务中所有服务器共同保证事务以串行等价方式执行。如果事务T对某一个服务器上对象的冲突访问在事务U之前，那么在所有服务器上对对象的冲突操作，事务T都在事务U之前。

加锁：在分布式事务中，某个对象的锁总是本地持有的。原子提交协议进行时对象始终被锁住，其它事务不能访问这些对象。

时间戳并发控制：对于单服务器事务，在开始执行时被分配一个唯一时间戳，通过按访问对象的事务的时间戳次序提交对象的版本来保证串行等价。

对于分布式事务，时间戳是一个二元组<本地时间戳，服务器id>对。先比时间戳再比服务器id。

乐观并发控制：每个事务在提交前必须进行验证。每个服务器验证访问自己对象的事务。验证在两阶段提交协议的第一阶段进行。允许多个事务同时进入验证阶段

。

6.6、分布式死锁产生原因及检测方法（集中、分布式）

在使用加锁机制进行并发控制时可能出现死锁。

锁超时很难设定时间间隔。

死锁检测通过寻找等待图中的环路实现，但全局等待图中的环路在局部等待中不存在，可能出现分布式死锁。

事务出现分布式死锁的例子：

分布式死锁的检测要求在分布于多个服务器的全局等待图中寻找环路。

各服务器只有局部等待图，需要通过通信才能发现全局环路。方法有：集中式死锁检测、边追逐方法。

集中式死锁检测：其中的一个服务器担任全局死锁检测器，全局死锁检测器收集局部等待图构造全局等待图。一旦发现环路，通知各服务器放弃相应事务解除死锁。

不足：依赖单一服务器执行检测，可靠性差，缺乏容错，没有可伸缩性，收集局部等待图的代价高。

边追逐法：无需构建全局等待图，服务器通过转发探询（Probe）消息发现环路。

边追逐算法：开始阶段：当服务器发现某个事务T开始等待事务U，而事务U正在等待另一个服务器上的对象时，该服务器将发送一个<T->U>的探询消息。

死锁检测：接收探询消息，确定是否有死锁和是否转发探询消息。

死锁解除：当检测出环路后，环路中的某个事务将被放弃打破死锁。

6.7、两阶段提交协议的恢复

第七章、复制

7.1、复制的概念、动机、基本要求

复制的概念：在多个节点上保存相同数据的一个副本。

一个拥有数据拷贝的节点称为副本管理器。

动机：容错。如果一些副本不能被访问，另外一些仍能够被访问。

可用性：在合理的响应时间内获得服务的次数所占比例应该接近100%。

正确性：允许一定数量和类型的故障。

基本要求：数据在同一个域中的多个服务器之间进行资源缓存和透明复制。

复制透明性：客户不需要知道多个物理副本。

一致性：不同应用一致性强度有所不同。

分布式系统的特点（CAP）：

Consistency(一致性)：所有节点在相同时间看到相同的数据（每个读操作都接收到最近的写）。

Availability(可用性)：无论节点的单个状态如何，每个请求都会获得（非错误）响应。

Partition(分区)：断链的情况，消息被丢弃或延迟。

7.2、复制的系统模型：主动复制、被动复制

基本模型：

基本模型组件：1、前端：接收客户请求，通过消息传递与多个副本管理器进行通信。为什么不让客户直接通信？（保证复制的透明性）

2、副本管理器：接收前端的请求，对副本执行原子性的操作，其执行等价于以某种严格顺序执行（保证复制的一致性）。

系统模型（副本操作）：1、请求：前端将请求发送至一个或多个副本管理器。2、协调：保证执行的一致性，对不同请求进行排序（FIFO序，因果序，全序）。3、执行：副本管理器执行请求（包括试探性执行，即执行效果可以去除）。4、协定：对于要提交的请求的执行结果达成一致。5、响应：根据应用需要，一个或者多个副本管理器响应前端（高可用性，容忍拜占庭故障）。

被动（主备份）复制（支持可线性化）：一个主副本管理器+多个次副本管理器。

被动请求时的事件次序：1、请求：前端将请求发给主副本管理器。2、协调：主副本管理器按接受次序对请求排序。3、执行：主副本管理器执行请求并存储响应。4、协定：若请求为更新操作，则主副本管理器向每个次副本管理器发送更新后的状态。5、响应：主副官管理器将响应发送给前端，前端将响应发送给客户。

主动复制（支持顺序一致性）：副本管理器地位对等，前端组播消息发送给副本管理器组。

主动复制时的事件次序：1、请求：前端使用全序、可靠的组播原语将请求组播到副本管理器组。2、协调：组通信系统以同样的次序（全序）将请求传递到每一个副本管理器。3、执行：每个副本管理器以相同的方式执行。4、协定：鉴于组播传递的语义，不需要该阶段。5、响应：每个副本管理器将响应发送给前端，前端将响应发送给客户。

7.3、单拷贝串行化的概念、“读一个\写所有”方案原理、适用条件及本地验证方法

单拷贝串行化：作用于复制对象的事务应该和它们在一个对象集上的一次执行具有一样的效果，这种性质叫做单拷贝串行化。

单拷贝串行化可以通过“读一个\写所有”实现复制方案。

“读一个\写所有”方案原理：读操作可以在任意一个可用副本管理器上执行。而写操作必须对所有副本管理器共同更新。

适用条件：读一个\写所有在副本管理器崩溃或者通讯故障时不是一个现实的方案（无法写所有）。

可用副本复制方案允许某些副本管理器暂时不可用。1、读请求可由任何可用的副本管理器执行。而写请求必须由所有可用的副本管理器执行。2、只要可用的副本管理器集没有发生变化（前提），本地的并发控制和读一个\写所有复制一样可以获得单拷贝串行化，但如果执行过程中副本管理器故障或恢复，需要额外验证。

本地验证：确保任何故障和恢复不会在事务执行时发生。事务提交前检查已访问的副本管理集是否变化（故障和恢复）。

7.4、闲聊系统的两个保证、体系结构（含关键数据结构）及基本操作

体系结构：前端可以选择副本管理器（可用且响应时间合理）。提供两种基本操作：查询+更新。副本管理器定期通过gossip消息来传递客户的更新。

两个保证：1、随着时间的推移，每个用户总能获得一致服务。副本管理器提供的数据能反映迄今为止客户已经观测到的更新。2、副本之间松弛的一致性。两个客户可能会看到不同的副本。客户可能观测到过时的数据。所有副本管理器最终将收到所有更新。

基本操作：查询和更新操作流程：

1、请求：前端将请求发送至副本管理器。

查询：前端阻塞

更新：默认前端立即返回，为提高可靠性，客户可以被阻塞到已经传给f+1个副本管理器后继续执行。

2、对更新的响应：副本管理器只要一收到更新就立即回答

3、协调：收到请求的副本管理器并不处理操作，直到它能根据所要求的次序约束处理请求为止。这可能涉及接收其他副本管理器以gossip形式发送的更新。

4、执行：副本管理器执行请求。

5、对查询的响应：副本管理器对查询请求作出应答。

6、协定：副本管理器通过交换gossip消息进行相互更新，gossip消息的交换是偶尔的。

在收集到若干更新后，或者发现丢失一个发送到其他副本管理器的更新，而在处理新请求时又需要这个更新，才会交换gossip消息。

第八章：分布式文件系统

8.1、分布式文件系统的需求

透明性：分布式文件系统应该如同本地文件系统。

访问透明性：客户无需了解文件分布性，通过一组文件操作访问本地/远程文件。

位置透明性：客户使用单一的文件命名空间。路径不变，多个文件应该可重定位。

移动透明性：当文件移动时，客户的系统管理表不必修改。

性能透明性：负载在一个特定范围变化时，性能可接受。

伸缩透明性：文件服务可扩充，以满足负载和网络规模增长的需要。

并发的文件更新：并发控制，客户改变文件操作不影响其他客户。

文件复制：分担文件服务负载，更好的性能和容错能力。

硬件和操作系统的异构性：接口定义明确，在不同操作系统和计算机上实现同样服务。

容错：

一致性：单个拷贝更新语义，多个进程并发访问或修改文件时，它们只看到仅有一个文件拷贝存在。

安全性：客户请求需要认证，访问控制基于正确的用户身份。

效率：性能满足一定要求。

8.2、文件服务体系结构，即三个组件、作用、接口、设计理念

三个组件：目录服务、平面文件服务、客户模块。

作用：

目录服务：元数据管理（包括修改、访问或创建文件时操作系统记录的时间）；创建或更新目录、提供文件名（Name）和平面文件结构中唯一文件标识（UFID）的映射。

平面文件服务：和unix进行比较，没有open和close操作，通过引用合适的UFID可以立即访问文件；read和write操作需要一个开始位置；可重复操作（除了create，其他操作都是幂等的）；无状态服务器（在文件上进行操作不需要读写指针，故障后重启无需客户或服务器恢复任何状态）

客户模块：支持应用程序对远程文件服务的透明存取。缓存最近使用的文件块提高性能。

接口：

目录服务：

平面文件服务：

8.3、NFS体系结构、NFS服务器操作、路径解析、缓存机制

NFS体系结构：

NFS服务器操作：访问控制和认证。

与传统的unix文件系统不同，NFS服务器是无状态的。

在用户发出一个新的文件请求时，服务器必须重新比对用户ID和文件访问许可属性，判断是否允许用户进行访问。（将用户ID绑定到每个请求，在NFS中嵌入Kerberos认证）

路径解析：UNIX文件系统（本地）每次使用open、create或stat系统调用时，一步步地将多部分文件路径名转换为inode使用。

NFS服务器（远程）不进行路径名转换，需要由客户以交互的方式完成路径名的翻译。

客户向远程服务器提交多个look up请求，将指向远程安装目录的名字的每一部分转换为文件句柄。

缓存机制：UNIX文件系统（本地）缓存：预先读、延迟写。

NFS（远程）缓存：服务器高速缓存（读写操作），客户高速缓存（请求结果）

NFS服务器缓存：NFS服务器的读缓存与本地文件系统相同。

NFS的写缓存，写操作提供两种选项：

1、写透：在给客户发送应答前先将应答写入磁盘（写操作的持久性），写透操作可能引起性能的瓶颈问题。

2、写透，但只在close()：写操作存储在内存缓存中，当系统接收相关文件的commit操作时（由于写而打开的文件关闭时），写入磁盘（提高性能）。

NFS客户缓存：为了减少传输给服务器的请求数量，NFS客户模块将read, write, getattr, lookup, readdir操作的结果缓存起来。

保持一致性：客户轮询服务器来检查他们所用的缓存数据是否是最新的。

基于时间戳的缓存块验证：缓存中的每个数据块被标上两个时间戳。Tc：缓存条目上一次被验证的时间。Tm：服务器上一次修改文件块的时间。T：当前时间。

有效性条件：（T-Tc＜t）或者（Tmclient = Tmserver）。t的取值对一致性和效率进行折中。（对服务器应用getattr操作获取文件的Tm属性）。

8.4、AFS应用场景、设计理念、缓存机制、一致性

AFS应用场景：

设计理念：大多数文件，更新频率小，始终被同一用户存取。本地缓存的磁盘空间很大。

设计策略基于以下假设：文件比较小，大多数文件小于10KB。读操作是写操作的6倍。通常都是顺序存取，随机存取比较少见。大多数文件是被某一个特定的用户访问，共享文件通常是被某一个特定的用户修改。最近使用的文件很可能再次被使用。

缓存机制：每个工作站本地磁盘上都有一个文件分区被用作文件缓存，保存共享空间中的文件拷贝，Venus进程管理这一缓存。

当文件分区已满，并且有新的文件需要从服务器拷贝过来时，它将最近最少使用的文件从缓存中删除。

缓存都足够大，当客户缓存已经包含了当前用户文件和经常使用的系统文件时，工作站可以基本独立于Vice服务器工作。

缓存一致性：回调承诺：由管理该文件的Vice服务器发送的一种标识，用于保证当其他客户修改此文件时通知Venus进程。

两种状态：有效或取消。

当一个Vice服务器执行一个更新文件请求时，它通知所有Venus进程将回调承诺标识设置为取消。

当客户打开文件：如果本地没有文件或者文件标识值为取消，Venus从服务器取得文件。如果标识值为有效，就直接用本地缓存的文件拷贝。

当客户关闭文件：如果副本被更新，Venus向Vice发送此副本。Vice替换此文件内容。Vice通知所有的文件缓存设置为取消状态。

当客户重启或者在时间T内没有收到回调信息，Venus认为该文件无效。

第九章：谷歌文件系统（GFS）

9.1、GFS设计动机

首先，组件失效被认为是常态事件，而不是意外事件。以通常的标准衡量，文件非常巨大。绝大部分文件的修改是采用在文件尾部追加数据，而不是覆盖原有数据的方法。应用程序和文件系统协同设计以提高整个系统的灵活性。

9.2、Master不存在性能瓶颈的原因

Master服务器在不同的数据文件里保持元数据。数据以64MB为单位存储在文件系统中。client和Master服务器通讯在文件上做元数据操作并且找到包含用户需要的数据。

9.3、读、写、添加操作流程

读操作流程：1、应用程序发起读取请求。2、client从（文件名，字节范围）->（文件名，组块索引）转换请求，并将其发送到Master。3、Master以块句柄和副本位置作为响应。4、client选择一个位置，将（块句柄，字节范围）请求发送到该位置。5、chunkserver将请求的数据发送到该位置。6、Client将数据转发到应用程序。

写操作流程：