Distributed System 基础（一）Distributed computation

W_dyyy

已于 2022-01-28 15:24:10 修改

阅读量521

点赞数 1

分类专栏： Distributed System 文章标签：分布式分布式计算分布式存储

于 2022-01-26 21:56:53 首次发布

本文链接：https://blog.csdn.net/qq_35455206/article/details/122707935

版权

Distributed System 专栏收录该内容

4 篇文章 0 订阅

订阅专栏

前言：

最近被ds课折磨的半死，新开个坑，总结下学到的东西，欢迎各位大佬交流补充。

1 介绍：

分布式系统是指在一个网络上分布了n个进程的系统。这些进程相互协同完成某个任务。通信系统是由连接每一对进程的信道组成的，这些信道可以使reliable的也可以是unreliable的(reliable 指信道中的信息一定会到达，但不保证顺序，如TCP/IP)。

异步（Asynchronous）:no time bound for message

同步（Synchronous）:have time bound for message,并且我们能假设在x秒后消息会到达

此外，我们不能假设进程的相对速度，有些是快的，有些是慢的，无法预测。

2进程时间线

接下来解释几个名词

global state(全局状态):local history的集合

local history:某进程的事件序列hi =

global history:

event:一个事件可能是进程内部的，并且只导致本地状态更改，也可能涉及与另一个进程的通信

run:某次分布式系统运行事件(event e)的总的顺序,我们定义run是因为同一个DS多次运行可能执行event的顺序并不相同

cut:a run stop at some point，是global history 的一个子集

在异步系统中，没有时间框架，于是我们使用"happen before"来表示两个事件之间的关系，即“→”，如图中表示的，在异步系统中我们可以看出来， gif.latex?e_%7B2%7D%5E%7B1%7D%5Crightarrow%20e_%7B1%7D%5E%7B2%7D ,但是 gif.latex?e_%7B3%7D%5E%7B1%7D 和却不存在这种关系，我们称为concurrent

3 consistency(一致性)

形式化定义(当且仅当): gif.latex?%5Cforall%20e%2Ce%27%20%2C%28e%27%5Cin%20C%29%20%5Cwedge%20%28e%5Crightarrow%20e%27%29%5CRightarrow%20e%5Cin%20C

则cut C是consistent的。在时间图中表示为所有happen before关系只能从cut线的左侧指向右侧，不允许从右侧指向左侧

4 deadlock

我们知道死锁可能发生在单个系统中，但与分布式系统没有区别。我们有两种主要的方法：避免死锁和消除死锁。后者是最实用的，如果DS处于死锁状态，则会定期检查并删除它，方法是添加一个进程p0，它可以询问系统的状态。

我们必须记住，系统是异步的，因此p0消息可以在不同进程的不同时刻到达。当p0接收到每个消息时，就可以构建一个图来表示进程之间的“等待情况。

5 clock(时钟)

我们假设有一个Global Real Clock,每一个进程都可以使用它来完美的对齐。虽然这在现实世界是不可能的事，但我们可以用协议来很好地模拟(NTP)。这样，我们能在每个进程每个event执行时发送message给p0，然后在某一时刻p0能收到这些信息，这样这些信息就能表示出这个run。但这个run是consistent的吗？答案是否定的，因为即使有全局时钟，和reliable的信道，到达的顺序依然可能是乱序的，于是我们需要用时间戳来label这些message，在到达p0的时候进行排序。那么这样得到的是consistent的吗？答案是肯定的，因为有（时钟条件 clock condition）：

gif.latex?e%5Crightarrow%20e%27%5CRightarrow%20RC%28e%29%3C%20RC%28e%27%29

不用双向等号的原因是e和e'不一定要有关系，有双等号称为强时钟条件。

如果我们不用RC，我们使用我们自己的clock呢？当然也是可以的，因为我们需要的只是一个顺序，并不需要那么确切的信息。但我们自己定的clock要符合以下条件：

1如果我们有sending event 或者internal event，加一。

2如果我们有一个receiving event，取internal event和sending event之间的最大值，加上1

符合以上规律的也被称为Lamport’s clock

此外，我们还有个问题：因为在分布式系统中（请记住，我们是有异步系统的），所以我们不确定在我们deliver之后会不会再来个时间戳(timestamp)更小的message。于是我们规定了deliver rule(DR)：

At time t, deliver all messages in order whose timestamp is smaller than t − ∆. (∆是time bound)

在同步分布式系统中，∆是他的time bound。即在∆时间后我们能确定该message一定到达了。

在异步分布式系统中，我们开始使用Lamport Clock

Defination 1：A message m is stable if no future message with timestamp smaller than TS(m)

can be received.

于是我们就用Lamport Clock得到了一个新的delivery rule(DR2)

Deliver all received messages that are stable in timestamp order.

Defination 2： The history of an event e1 is: gif.latex?%5CTheta%20%28e1%29%3D%5Cleft%20%5C%7B%20e%7Ce%5Crightarrow%20e1%20%5Cright%20%5C%7D%5Ccup%20%5Cleft%20%5C%7B%20e1%20%5Cright%20%5C%7D

gif.latex?%5CTheta%20%28e1%29%3D%5Cleft%20%5C%7B%20e%7Ce%5Crightarrow%20e1%20%5Cright%20%5C%7D%5Ccup%20%5Cleft%20%5C%7B%20e1%20%5Cright%20%5C%7D

我们现在会发现Θ集只是我们跟在强时钟条件之后的时间戳(并且它也是一个一致性的cut)

我们可以用一个n维数组来表示这个集合，其中n是进程数量，在这个数组中每个元素我们用每个进程最大的最后一个(最大的)时间戳来表示。这样的数组我们称为 Vector Clock

通过时间戳的比较我们知道了两个事件是否有happen before 关系，或者concurrent关系。

6 Snapshot

这是一个由Chandy 和 Lamport设计的协议(也叫Chandy-Lamport protocol)该协议利用了FIFO信道。

p0通过向其它进程发送ts(take snapshot)message 来take snapshot。当其他进程第一次收到该ts消息时，它会take snapshot 然后向其他所有进程广播ts消息(除了p0)

问：我们怎么知道协议什么时候终止？

答：当每个进程都收到n个ts 消息时，协议终止

问：我们怎么知道snapshot是consistent的？

答：

假如说snapshot不是consistent的，根据consistent的定义我们有 gif.latex?e%5Crightarrow%20e%5E%7Bi%7D%20%5Cwedge%20e%5E%7Bi%7D%5Cin%20S%5CRightarrow%20e%5Cnotin%20S

所以我们可以有如上图的关系。我们假定有snapshot1 发生在e之前，snapshot2 发生在 gif.latex?e%5E%7Bi%7D 之后。当p3 收到p0的ts消息(snapshot1)之后会广播给p2,p2就会收到一个ts消息，并且这个消息会在snapshot2之后到达，但这是不可能的，因为信道是FIFO的，而s1是在e之前的，所以s1一定在e'之前到达。