Distributed System 基础(一)Distributed computation

前言:

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

1 介绍:

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

异步(Asynchronous):no time bound for message

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

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

2进程时间线

0478ad47472c47fab4a21abe78358a77.png

接下来解释几个名词

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

local history:某进程的事件序列hi = gif.latex?e_%7Bi%7D%5E%7B1%7De_%7Bi%7D%5E%7B2%7D... 

global history: gif.latex?H%3Dh_%7B1%7D%5Ccup%20h_%7B2%7D...

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%7Dgif.latex?e_%7B2%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 1A 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 .
我们现在会发现Θ集只是我们跟在强时钟条件之后的时间戳(并且它也是一个一致性的cut)
 
我们可以用一个n维数组来表示这个集合,其中n是进程数量,在这个数组中每个元素我们用每个进程最大的最后一个(最大的)时间戳来表示。这样的数组我们称为 Vector Clock
39b5b398680d4b60ae11ae3924595fa8.png

 通过时间戳的比较我们知道了两个事件是否有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的?

答:

8fa408b8e06d477095bb0f33c0456f62.png

假如说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'之前到达。 

 

 

  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值