2017电子科技大学分布式系统考点

第一章概述
⏹分布式系统的目标
⏹资源共享(resource sharing)
⏹计算机通过网络连接起来，并在这个范围内有效地共享资源
⏹硬件的共享，软件的共享，数据的共享，服务的共享
⏹媒体流的共享（动态的资源形式）
⏹协同计算(collaborative computing)
⏹并行计算，分布式计算
分布式系统是指把多个处理机通过网络互连而构成的系统，系统的处理和控制功能分布在各个处理机上。

⏹分布式系统的问题源于下面三个特点：
⏹并发性（concurrence)
⏹多个程序（进程，线程）并发执行，共享资源
⏹没有全局时钟(global clock)
⏹每个机器都有各自的时间，没有办法做到统一，程序间的协调靠交
换消息
⏹故障独立性(independent failure)
⏹一些进程出现故障，并不能保证其它进程都能知道
分布式的挑战异构性:网络协议, 硬件, 操作系统, 编程语言, 开发者实现方式的不同.
开放性:
可扩展性:
安全性: 机密性: 防止未经授权的个人访问资源
完整性: 防止数据被篡改和破坏
可用性: 防止对所提供服务的干扰
故障处理: 检测故障, 屏蔽故障, 故障容错, 故障恢复, 冗余策略
并发: 正确性: 多个进程并发访问共享资源，要保证被访问数据的正确性，不能出现不一致。

性能: 多个并发操作保证性能
透明性: 访问透明:使用同样的操作去访问本地资源和远程资源。

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

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

复制透明: 使用多个资源的副本来提高可靠性和性能，用户或者应用程序开发者并不需要了
解副本技术。

故障透明,移动透明,性能透明,扩展透明
第二章系统模型
⏹结构模型
构成系统各部分（components, computers, procedures )
的位置、角色和它们之间的关系，它定义了系统的各组件之
间相互交互的方式以及它们映射到下面的计算机网络的方
式。

⏹客户/服务器结构
⏹对等结构（客户/服务器模型的变种）
基础模型
⏹体系结构模型所涉及的问题：
⏹系统中的主要实体是什么？
⏹它们如何交互？
⏹影响他们单个和集体行为的特征是什么？
模型的目的
⏹显式地表示有关正在建模的系统假设；
⏹给定这些假设，就什么是可行的，什么是不可行的给出结论。

交互模型
⏹通信性能
⏹不可能维护一个全局时间概念
同步分布式系统
⏹进程执行每一步的时间有一个上限和下限。

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

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

异步分布式系统---没有可预测的时限
⏹进程执行速度
⏹每一步都可能需要任意长的时间
⏹消息传递延迟
⏹收到一个消息的等待时间可能任意长
⏹时钟漂移率
漂移率可能是任意的
故障模型
⏹遗漏故障Omission failures
⏹随机故障Arbitrary failures
⏹时序故障Timing failures
安全模型
⏹进程的安全性
⏹通信信道的安全性
⏹对象的安全性
⏹交互模型：时序问题，不能一个人看到的回答先于问题到达。

⏹故障模型：消息丢失，保证每个组成员都要收到相同的消息。

⏹安全模型：消息的加密。

第三章时间和全局状态(重点)
Cristian方法(理解)
应用条件
-存在时间服务器，可与外部时间源同步
-消息往返时间与系统所要求的精度相比足够短
协议
-进程p根据消息mr，mt计算消息往返时间Tround
-根据服务器在mt中放置的时间t设置时钟为：t+Tround/2
精度分析
若消息的最小传输时间为min ，则精度为： (T round /2 – min)
(注意：可暂时不考虑从 A 到B 和从B 到A 的消息传 输 路
径 不 同 而导致 的 传输时
间 不同)
---S 在m t 中放置时间最早点是在p 发出m r 之后的min ---应答消息到达时S 的时钟时间位于[t+min,t+T round -min] ---上面的范围宽度是T round -2min
t p
时间服务器S
t
t +T round /2
min
t +T round
网络时间协议(NTP)
设计目标
-可外部同步
使得跨Internet的用户能精确地与UTC(通用协调时间)同步-高可靠性
可处理连接丢失，采用冗余服务器、路径等-扩展性好
大量用户可经常同步，以抵消漂移率的影响-安全性强
防止恶意或偶然的干扰
协议结构
-层次结构
-主服务器直接与外部UTC同步
-同步子网可重新配置
NTP三种同步模式
-组播
适用于高速LAN
准确度较低，但效率高
-过程调用
与Cristian算法类似
准确度较低
-对称模式---按对称模式操作的一对服务器交换有时序信息的消息
保留时序信息
准确度最高
如下图所示，有P1、P2、P3三个进程以及发生的事件a，b，c，…，假定逻辑时钟的初始值为0。

1) 为每个事件标定Lamport 时钟。

2) 为每个事件标定全序逻辑时钟。

3) 为每个事件标定向量时钟。

4) 割C1，C2是否是一致割集，如果不是为什么？
P1
P2
P3
Lamport时钟
全序逻辑时钟（T,Pi）Pi为进程号
向量时钟 每个进程维护它自己的向量时钟Vi ，如图3个进程3个分量
全局状态——单个进程状态的集合 S = (s1, s2, … sN) 割集——系统全局历史的子集 C = <h1c1, h2c2… h3c3 > 割集的一致性
割集C 是一致的: 对于所有事件e ∈C , f →e ⇒f ∈C
一致的全局状态——对应于一致割集的状态
S 0→ S 1→ S 2→ …
p 1
p 2
p 3
Physical ti me
“快照”算法
进程pi的标记接收规则
pi接收通道c上的标记消息：
if (pi还没有记录它的状态)
pi记录它的进程状态；
将c的状态记成空集；
开始记录从其他接入通道上到达的消息
else
pi把c的状态记录成从保留它的状态以来它
在c上接收到的消息集合
end if
进程p i的标记发送规则
在p i记录了它的状态之后，对每个外出通道c:
(在p i从c上发送任何其他消息前)
p i在c上发送一个消息标记
分布式调试
判定可能的
从初始状态开始，遍历可达状态的网格。

L:=0;
States:={(s 01, s 02, …, s 0N )};
while (对所有可能的S∈States，φ(s)=False)
L:=L+1;
Reachable:={S’: H 中从一些S∈States 可到达的状态∧level(S’)=L}; States:=Reachable;
end while
输出“可能的φ”;见书上P.368的求解明确的φ
可能的和明确的区别：从初始状态开始，经过从这点开始可到达的所有一致状态，在每一步
判定φ。

当φ判定为T 时停止计算。

为了判定明确的φ，监控器进程必须试图找到所有线性化走向必须经过的φ判定为T 的状态集
第四章 协调和协定(重点)
基于环的算法：构架（进程安排在一个逻辑环中，每个进程pi 与环中下一个进程p （i+1）
mod N 有一个通信信道）
满足安全性和活性要求，但不满足顺序要求。

- 客户延迟
Min: 0个消息，正好收到令牌 Max: N 个消息，刚刚传递了令牌
- 同步延迟
Min: 1个消息，进程依次进入临界区
Max: N个消息，在一个进程离开和下一个进程进入临界区之间的同步延迟。

使用组播和逻辑时钟的算法：
进程进入临界区需要所有其它进程的同意
初始化:
state:=RELEASED;
为了进入临界区
state:=WANTED;
组播请求给所有进程;
T:=请求的时间戳;
Wait until (接收到的应答数=(N－1));
state:=HELD;
在p j(i≠j)接收一个请求<T i,p i>
if (state = HELD or (state = WANTED and (T, p j) < (T i, p i)))
t hen将请求放入p i队列,不给出应答;
else马上给p i应答;
end if
为了退出临界区;
state := RELEASED;
对已进入队列的请求给出应答;
满足安全性、活性和顺序要求。

- 客户延迟
1个消息往返时间
- 同步延迟
1个消息的传输时间
基于环的选举算法
在异步系统中选举具有最大标识符的进程作为协调者
－最初，每个进程标记为非参与者
－任何进程可以开始一次选举
将自身标记为参与者
id msg = id local , 发送选举消息{elect, id msg}至邻居－接收到选举消息{elect, id msg}时：
自身id小于消息中的id，即id local< id msg
✓转发消息并将自身标记为参与者
自身id大于消息中的id，即id local> id msg
✓若自身标记为参与者，则不转发消息
✓若自身标记为非参与者，则发送{elect, MAX(id local,
id msg)}至邻居，并将自身标记为参与者
当id local=id msg时，该进程成为协调者，发送{elected,
id coordinator }至邻居，邻居节点依次转发该消息，并设置协调
者信息，直至该消息再次到达协调者。

霸道算法
下面解释有助理解，考的是算法
⏹知道自己有最大标识符的进程通过发送协调者消息给所有具有较小标识符的进程，
选举自己。

⏹有较小标识符的进程通过发送选举消息给那些有较大标识符的进程，开始一次选举，
并等待应答消息。

⏹如果它具有最大的进程标识符，它会决定自己是协调者，并向其他进程宣布。

该算
法为“霸道算法”。

算法：
- 选举初始化
进程P在发现协调者失效后启动一次选举，将选举消息发送给具有更大标识符的进程。

- 接收进程回送一个回答并开始另一次选举
- 协调者发送协调者消息
若进程P 没有收到回答消息，则给所有具有较小标识符的
进程发送协调者消息。

若进程P 收到回答消息，则等待协调者消息；若消息在一
段时间没没有到达，则启动一次新的选举算法。

- 进程收到协调者信息后，设置elected i = id coordinator
用IP组播实现可靠组播
组g中的每个进程维护一个序号
S g p: 下一个要传送的消息序号。

R g q: 来自进程q的最新消息序号。

进程p要R-multicast一个消息到组g: 捎带S g p和确认; S g p = S g p +1。

R-deliver一个消息m:
1. 当且仅当m.S = R g p +1传递消息；R g p = R g p +1
2. 若m.S<= R g p, 则该消息已传递，直接丢弃。

3. 若m.S>R g p+1或对任意封闭的确认<q, R g q>有m.R>R g q, 则漏掉了一个或多个消息,将
消息保留在保留队列中,并发送否认确认。

全排序如果一个正确的进程在传递m’前传递消息m，那么其它传递m’的正确进程将在m’前传递m，只要该顺序在不同进程中是一样的即可，不必是FIFO或者因果.
使用顺序者的全排序算法
1. 组成员p的算法
初始化：r g:=0;
为了给组g发TO-multicast消息：
B-multicast(g∪{sequencer(g)},<m,i>);
i是m的一个唯一标识符。

在B-deliver(M order=<“order”,i,s>)时，其中g=group(M order)
Wait until <m,i>在保留队列中并且S=r g;
To-deliver m; //在从保留队列删除它之后
r g=S+1;
2. 顺序者g的算法
初始化：s g:=0;
在B-deliver(<m,i>)时，其中g=group(M order)
B-multicast(g,<“order”,i,s g>);
s g:=s g+1;
基于顺序者的算法缺点：顺序者会成为瓶颈
拜占庭将军问(共识问题) N进程，f错误
随机故障假设
- N个进程中最多有f个进程会出现随机故障
N≤3f
- 无解决方法
N≥3f+1
- Lamport于1982给出了解决算法
第五章事务和并发控制(重点)
乐观并发控制
向后验证
1.检查它的读集是否和其它较早重叠事务的写集是否重叠---要做，规则2
2.检查它的读集是否和其它较早重叠事务的读集是否重叠---不需要做
算法
- startTn: T v进入工作阶段时已分配的最大事务号码- finishTn: T v进入验证阶段时已分配的最大事务号码
验证失败后，冲突解决方法
放弃当前进行验证的事务
事物的验证过程
- T1、T2、T3是较早开始的事务
- T1在T v开始之前提交
- T2、T3在T v完成其工作阶段前提交
- startTn+1=T2，finishTn=T3
向前验证
比较Tv的写集合和所有重叠的活动事务的读集合---规则1 活动事务是那些在工作阶段中的事务，并无事务号
算法
- 设活动事务具有连续的事务标示符active1~activeN
验证失败后，冲突解决方法，几个策略：
- 放弃当前进行验证事务
- 推迟验证
- 放弃所有冲突的活动事务，提交已验证事务。

事物的验证过程
- T1、T2、T3是较早开始的事务
- T1在Tv开始之前提交
- T2、T3在Tv完成其工作阶段前提交
- startTn+1=T2，finishTn=T3
向后验证将较大的读集合和较早事务的写集合进行比较向前验证将较小的写集合和活动事务的读集合进行比较
时间戳排序
时间戳排序的写规则
是否接受事务Tc对对象D执行的写操作
时间戳排序的读规则
是否接受事务Tc对对象D执行的读操作
第六章复制(重点)
系统模型
基本模型组件
副本管理器
- 接收前端请求
- 对副本执行原子性操作
前端
- 接收客户请求
- 通过消息传递与多个副本管理器进行通信
副本对象的操作
请求：前端将请求发送至一个或多个副本管理器
协调
- 保证执行的一致性
- 对不同请求进行排序（FIFO，因果，全序）
执行：包括临时请求的执行
协定：就提交请求的影响达成一致
响应：一个或多个副本管理器响应前端
被动(主备份)复制
一个主副本管理器＋多个次副本管理器
- 若主副本管理器出现故障，则某个备份副本管理器将提升为主副本管理器。

模型
被动复制时的事件次序
请求
- 前端将请求发送给主副本管理器
协调
- 主副本管理器按接收次序对请求排序
执行
- 主副本管理器执行请求并存储响应
协定
- 若请求为更新操作，则主副本管理器向每个备份副本管理器发送更新后的状态、响应
和唯一标识符。

- 备份副本管理器返回确认。

响应
- 主副本管理器将响应发送给前端
- 前端将响应发送给客户
主动复制
副本管理器地位对等，前端组播消息至副本管理器组
模型
主动复制时的事件次序
请求
- 前端使用全序、可靠的组播原语将请求组播到副本管理器组协调
- 组通信系统以同样的次序(全序)将请求传递到每个副本管理器执行
- 每个副本管理器以相同的方式执行请求
响应
- 每个副本管理器将响应发送给前端
- 前端将响应发送给客户
gossip体系结构
查询和更新操作流程
请求
- 前端将请求发送至副本管理器
查询：客户可能阻塞
更新：无阻塞
更新响应
- 副本管理器立即应答收到的更新请求
协调
- 收到请求的副本管理器并不处理操作，直到它能根据所要求的次序约束处理请求为止。

执行
- 副本管理器执行请求
查询响应
- 副本管理器对查询请求作出应答
协定
- 副本管理器通过交换gossip消息进行相互更新
gossip消息的交换是偶尔的
发现消息丢失后，才和特定的副本管理器交换消息
查询操作
副本管理器收到查询
一个查询请求q包含操作的描述和一个前端发送的时间q.pre，这个值反映了前端已读到或
作为更新已提交的值最新版本。

- q.pre≤valueTS（副本管理器的值时间戳）
立即响应
返回消息中的时间戳为valueTS
- 否则
副本管理器将消息保存到保留队列（将要执行的操作表），
等待丢失的更新，能从相关副本管理器获取更新。

前端收到查询响应
- 合并时间戳：frontEndTS:=merge(frontEndTS,new)(2,5,6)
按因果次序处理更新
前端发送更新请求：发送同样的请求u给若干副本管理器。

副本管理器i接收请求
- 丢弃：操作已经处理过，根据已执行操作表和它的日志中的记录
- 否则，将更新记录日志
- 副本管理器将ts返回给前端，ts是副本服务器分配给更新的唯一时间戳。

更新请求u的稳定性条件
u.prev≤valueTS
即所有由发起更新的前端观察到的更新已经执行了，指副本服务器？
如果更新提交时这个条件不满足，它将在闲聊消息到达时重新检查。

副本管理器的更新操作
第七章分布式文件系统
组件
文件服务的三个组件
平面文件服务
对文件内容进行操作
唯一的文件标识（UFID），用于在所有平面文件服务操作的请求中标识文件
UFID是一长串比特，每个文件的UFID在分布式系统的所有文件中是唯一的
目录服务
提供文件名到UFID的映射
客户模块
提供应用程序对远程文件服务透明存取的支持，可供客户计算机上的用户级程序使用如对目录的迭代请求，缓存文件
NFS服务器缓存
NFS服务器的读缓存
和本地文件系统相同
NFS服务器的写缓存：增强可靠性
写透缓存：客户发出的Write操作中的数据存储在服务器的内存缓存中，在给客户发送应答前先将应答写入磁盘。

Write操作中的数据只存储在内存缓存中。

但客户
可以相信：数据被服务器持久地存储起来了
提交操作：当文件关闭时，发送一个commit，数据被写入磁盘中。

客户收到相关文
件的该操作应答，客户可肯定数据被持久地存储了。

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

有效性条件
缓存中的每个数据块被标上两个时间戳
Tc：缓存条目上一次被验证的时间。

Tm：服务器上一次修改文件块的时间。

有效性条件：(T- Tc < t) ∨(Tm client = Tm server)（或者）
减小对服务器进行getattr调用的几种方法
当客户收到一个新的Tm server值时，将该值应用于所有相关文件派生的缓存项。

将每一个文件操作的结果同当前文件属性一起发送，如果Tm server值改变，客户便可用它来
更新缓存中与文件相关的条目。

采用自适应算法来设置更新间隔值t，
写缓存
关闭文件时将文件写到服务器
周期性进行同步写
AFS的缓存策略
客户机的用户进程向共享文件空间内的一个文件发出Open系统调用，如果该文件的副本不在本地缓存上，AFS查找文件所在的服务器，向其请求传输文件的一个副本
在客户机上存储文件副本，存储在客户计算机的本地UNIX文件系统中，文件拷贝被打开，相应的UNIX描述符返回客户
客户在本地副本上进行读/写（Read/Write）
客户关闭文件
如果文件被更新，将它刷新至服务器，服务器更新此文件的内容和时间戳
客户本地磁盘上的拷贝一直被保留，以供在同一工作站上的用户级进程下一次使用
由于大部分请求为读请求，与轮询相比，客户与服务器间的交互显著减少
第八章谷歌文件系统GFS
GFS的设计思想
文件以数据块的形式存储
数据块大小固定，每个数据块拥有句柄。

利用副本技术保证可靠性
每个数据块至少在3个块服务器上存储副本。

每个数据块作为本地文件存储在Linux文件系统中。

主服务器维护所有文件系统的元数据
每个GFS簇只有一个主服务器。

利用周期性的心跳信息更新服务器。

客户端无需缓存数据，只需缓存元数据。

GFS的体系结构(阅读和理解)
什么是主服务器？GFSmaster
在独立的主机上运行的一个进程
存储的元数据信息：
文件命名空间
文件到数据块的映射信息
数据块的位置信息
访问控制信息
数据块版本号
文件数据块：64MB的大数据块,将文件存储在固定大小的块中
优点：
减少master上保存的元数据的规模，使得可以将metadata（元数据）放在内存中。

Client在一个给定块上很可能执行多个操作，和一个块服务器保持较长时间的TCP连接可
以减少网络负载。

在client中缓存更多的块位置信息。

缺点：
一个文件可能只包含一个块，如果很多client访问该文件，存储块的块服务器可能会成为访
问热点。

块位置信息
Master并不为块服务器的所有块的副本保存一个不变的记录。

Master在启动时或者在有新的client加入这个簇时通过简单的查询获取这些信息。

Master可以保持这些信息的更新，因为它控制所有块的放置并通过心跳消息（heartbeat）
来监控。

内存数据结构
master的操作很快，所以master可以轻易而且高效地定期在后台扫描它的整个状态。

块垃圾收集。

为平衡负载和磁盘空间而进行的块迁移。

块服务器出现故障时的副本复制。

整个系统的容量受限于master的内存，64KB/64MB。

如果一个块大小采用64KB，元数据量将增加1000倍。

若要支持更大的文件系统，那么增加一些内存的方法对于我们将元数据保存在内存中所获得的简单性、可靠性、高性能和灵活性来说，只是一个很小的代价。

主服务器和块服务器之间的通信（GFS master 和GFS chunkserver）
定期地获取状态信息
块服务器是否关闭？
块服务器上是否有硬盘损坏？
是否有副本出错？
块服务维护哪些块的副本？
主服务器发送命令给块服务器：
删除已存在的块。

创建新的块。

操作日志
操作日志包含了对metadata（元数据）所作的修改的历史记录，被复制在多个远程块服务
器上。

它可以从本地磁盘装入最近的检查点来恢复状态。

它作为逻辑时间基线定义了并发操作的执行顺序。

文件、块以及它们的版本号都由它们被创建时的逻辑时间而唯一地、永久地被标识。

Master可以用操作日志来恢复它的文件系统的状态。

服务请求：
Client 从主服务器检索元数据（metadata ）。

在client 和主服务器之间读/写数据流。

单个主服务器并不会成为瓶颈，因为它在读/写操作中的工作量很小。

Google 是通过减少client 与主服务器的交互来解决的，client 均是直接与chunkserver 通信， 主服务器仅仅提供查询数据块所在的chunkserver 以及详细位置。

GFS 的读操作（重点）
计算数据块位置信息：（假设：文件位置在201,359,161字节处）
应用程序发出读请求。

Client 将请求转换为（文件名、块位置），然后发送
给主服务器。

主服务器返回数据块的指引信息和副本位置信息。

Client 选择其中一个位置信息，并给那个块服务器发送请求。

块服务器返回请求的数据。

Client 将数据传送给应用程序。

第九章P2P系统
P2P应用层路由优势
系统扩展性强，避免单点失效
变不可达为可达，变慢速为快速Skype
屏蔽物理网络路由的错误
提供匿名访问功能
P2P的激励机制
BT客户端使用Tit for Tat激励对方贡献共享数据
记录自己过去从其它Peer下载的速度，优先给那些下载速度快的Peer提供上传。

乐观原则：从来没有给自己上传过内容的Peer中随机选择一些来上传
一致性哈希
1）首先求出每个服务节点的hash，并将其配置到一个0~232的圆环（continuum）区间上。

2）其次使用同样的方法求出所需要存储的key的hash，也将其配置到这个圆环（continuum）上。

3）然后从数据映射到的位置开始顺时针查找，将数据保存到找到的第一个服务节点上。

如果超过232仍然找不到服务节点，就会保存到第一个服务节点上。

分布式哈希表(DHT)
1.将内容索引抽象为<K, V>对:
K是内容关键字的Hash摘要
V是存放内容的实际位置，例如节点IP地址等
2. 所有的<K, V>对组成一张大的Hash表，因此该表存储了所有内容的信息
3.每个节点都随机生成一个标识(ID)，把Hash表分割成许多小块，按特定规则分布到网络
中
去，节点按这个规则在应用层上形成一个结构化的重叠网络
4.给定查询内容的K值，可以根据K和节点ID之间的映射关系在重叠网络上找到相应的V 值，从而获得存储文件的节点IP地址
Chord算法:
Hash节点IP地址－>m位节点ID(表示为NID) m=6环中最大节点号为N64(2^6)
节点按ID从小到大顺序排列在一个逻辑环上，<K, V>存储在后继节点上。

Successor (K)：从K开始顺时针方向距离K最近的节点
节点S的第i个指针successor[n+2^(i-1)], 1≤i≤m。