分布式操作系统2(3)剖析

整理文档很辛苦,赏杯茶钱您下走!

免费阅读已结束,点击下载阅读编辑剩下 ...

阅读已结束,您可以下载文档离线阅读编辑

资源描述

发送和接收原语RPC是一个比send和receive更常使用的通讯机制,它很难与组通信相融合。给一个组发送一条消息不能作为一个过程调用。因为在RPC中,客户发送一条消息到服务器,之后返回一个结果,但在组通信中,对一条请求可能会有N个应答,如何能处理这N个应答呢?因此,一个常用的方法就是采用单向通信模型send和receive的显式调用,而不采用基于RPC的双向通信模型请求/应答(request/reply)。应答的消息本身是独立的消息,与先前的请求不相关。有时也需要得到与请求相关的应答,以此来接近RPC的通信的方式。在这种情况下,在发送一条消息后,而要启动一个进程重复调用getreply来收集所有应答,每调用一次getreply可收到一个应答。有些系统引入新的库例程,group-send,group-receive。原子性一条消息发送给一个组后,不是该组所有成员都正确收到,就是均未收到,不允许出现组内有些成员收到而有些成员收不到的情况。具有要么全有要么全无的传递叫做原子性或原子广播通信。原子性可使分布式系统编程容易得多。当一进程发送消息给组时,不必担心如果组成员没有收到消息该怎么办。实现原子广播通信并起来那么简单。因为接收超时是经常可能出现的。确保每一台机器都能收到每一条消息,唯一的办法是要求所有机器收到消息时发回一个确认消息。许多分布式系统以容错为目标,对这些系统来说,在出现机器故障时仍能保持原子性是很重要的。有一种简单的算法证明原子广播通信至少是可能的。发送者以发送一条消息给所有组成员开始。设置一时钟并在必要的时候重发消息。当一个进程接收到一条消息时,如果它还没有看到这一特殊的消息,它就将该消息转发给组内其他成员。如果进程已经看到了这个特殊消息,就不必做这一步了,并且将该消息丢弃。这样,不管有多少个机器崩溃或有多少个信包被丢失,最终所有幸存的进程都将收到该消息。以后我们将讨论实现原子性的更有效的算法。消息的顺序要使组通信易于理解和使用:首先是原子广播通信,确保了一条消息要么被所有的组内成员收到,要么没有一个成员能收到。第二涉及到消息的发送顺序。进程0、1、3、4属于同一个进程组。进程0与4同时想给该组发送一条消息。如(B)图,进程4与0的两条消息以不同的顺序到达了进程1和3。如果进程0和4都想去改变数据库中的同一记录的值,那么进程1和进程3执行的最终结果是不相同的。系统必须很好地定义消息传递顺序的语义。最好的保证就是立即发送所有消息并让它们保持发送的顺序。如果进程0发送A消息,稍后进程4发送B消息,系统应先将消息A发送给组内各成员,然后冉将消息B发送给组内各成员,这样所有接收者都可以同样的顺序收到消息。这种将消息精确地按发送顺序传递到目的地的方法称为全局时间顺序。一致时间顺序是指若有两条消息A和B,以很小的时间间隔发送,系统保证组内成员按同样的顺序收到了各条消息,但这个顺序可能并不是发送消息的顺序。组的重叠一个进程能够同时成为多个组的成员。然而,这导致了新的不合理性。下图中有组1和组2两个组。进程A、B、C是组1的成员,进程B、C、D是组2的成员。现A与D同时向它们所在的进程组发送消息,组内采用全局时间顺序,A与D采用单点传送的方法。B先收到下A的消息后收到D的消息,而C则相反。尽管在组内都采用全局时间顺序,但在组间还需要协调。一些系统支持重叠组中的精确定义的时间顺序,有些系统不支持。在不同的组间实现一致的时间顺序是很困难的,有时不值得去做。可测量性如果进程组内只有几个成员,将工作良好。但如果组内有数十个、数百个以至成干上万个成员,或进程组时会怎样?或者,整个系统不限于一个局域网,而是有网关连接的际网,那么这些算法能实现并有效吗?网关的出现会影响我们实现中的许多特性,首先,多点广播更复杂,如图所示网络,它由四个LAN与四个网关构成。在LAN2有一机器发出了一个多点广播的消息,当多点广播的信包到达网关G1和G3时,若网关丢弃这个信包,则其他三个子网就无法看到该消息。若G1与G3将消息转发,那么消息到达了LANl与LAN4,然后分别通过G2与G4都到达LAN3,这样LAN3会收到两次这样的信包。由于四个子网构成一回路,且又采用了多点广播,经过G4的消息发往了G2到达LANl,经过了G2的消息发往了G4到达LAN4,最终部会回到LAN2。这需要更复杂的算法通过跟踪信包在网上的传送路径来避免信包被成倍地多点广播。另一个问题是一个内部网上的组通信利用LAN上某一瞬间只能传送一个信包的事实。实际上,信包在网上按绝对全局时间顺序发送是很重要的。但是在带有网关的多个子网构成的网上,同时刻传送两个信包,就破坏了绝对企全局时间顺序要求的某一时刻只有一个信包在网上传递的性质。在ISIS中的组通信ISIS是组合软件调用系统,它并不是完全意义上的操作系统,而是运行在UNIX或其他操作系统上的一组程序。在ISIS中的关键思想是同步,它的主要通信原语是不同形式的原子广播。同步系统是指一个每个事件都严格按序发生,并且每个事件的完成不需要时间。如图(a)松散同步系统中图2-34(b)每个事件占用有限的一段时间,但所有的事件会以同样的顺序在所有成员那里出现,与一致时间顺序是相同的。还可以采用一些更松散的语义,以提高性能。图2-34(c)中给出了一个虚拟同步系统。在这个系统中放宽了对顺序的限制但是在仔细选择的环境下,还是可以同步的。在分布式系统中,如果第一个事件可能会影响第二个事件的性质和行为则这两个事件是因果关系。如果两个事件间存在影响,那么就让它存在。无关的两个互不影响的事件称为并发。我们所说的虚拟同步就是,若两条消息是因果相关的,那么所有接收进程必须以同样的顺序接收它们,若两条消息是并发的,那么就不必以同样的顺序接收。系统可以随意地将这些消息以不同的顺序传递给不同的进程。ISIS中的通信原语ISIS中定义了三种通信原语ABCAST,CBCAST,GBCAST。ABCAST提供松散同步通信,用于向组成员传送数据。CBCAST提供虚拟同步通信,也用于向组成员传送数据。GBCAST与ABCAST类似,用于管理组内成员而不传送普通数据。通常ABCAST使用两阶段提交协议。其工作情况如下:发送者A分配一时间戳(仅是一个序号),将它放在一消息中,发送给组内各成员。各成员将自己的时间戳返回给A,该时间戳应大于该成员以前所收发的任何时间戳。当A收到所有时间戳后,A选择最大的一个,并将提交消息发给各成员。提交消息按时间戳大小提交给各应用程序。这协议保证了所有消息将按同样的顺序投递给各过程。ABCAST复杂且昂贵,设计者提出了CBCAST,它仅仅保证了所有因果相关的消息能按序发送到目的地。其工作情况:如果一个组有n个成员,每个成员进程保存一个n维向量,向量的每一维对应一个成员。第i维的值就是从进程i发过来的最后一次消息的序号。这向量由运行系统来控制(初始化为0)。进程有消息要发送时,它在自己保存的向量中属于自己的位置上加l,然后将该向量放在消息中。如图2-35的顶部。决定对到来的消息是接收还是推迟的算法描述如下:Vi是发送方向量中的第i位。Li是接受方向量的第i位。假设消息由j发送。接收的第一个条件是Vj=Lj十1,表明这是j进程发送来的下一条消息Vj,以前的消息均已收到没何遗漏。第二个条件:对所有的ij有Vi=Li.(j一定,i为变量)表明接受方己有所有发送方收到的消息。如果到来的消息通过这两个条件,那么运行系统可将消息送给本机上的用户进程。否则该消息必须等待。图2-36,进程0向其他五个成员发送消息,消息包含向量(4,6,8,2,1,5)。进程l的除0以外的其他位与0进程的相同,表明进程0收到的那些消息进程l也收到了。而进程l刚发送一条消息,进程0未收到,但这并不影响进程l接收消息。此外,进程1上的对应0的那位刚好比进程0的相应位小1,这样进程l接收进程0来的消息4。进程2的向量表明尚未收到进程1发来的消息6,进程2还不能接收进程0发来的消息。进程3看上去也收到了发送者收到的其他消息,进程3甚至收到进程1的消息7,只是还没有收到来自进程0的消息,因而,进程3可以接收进程0来的消息4。由于进程4向量对应的进程0的位置上的值是2,这就说明进程4丢失了进程0发来的消息3,因而进程4就不能接收进程0发来的消息4。在进程5中,该向量在0进程的位置上刚好比进程0少1,而且它比进程0先收到了来自进程1的消息,因而,它可以接收进程0来的消息4。小结分布式系统中提出和实现了通信的不同方法。对于相对传送速度较慢的广域分布式系统来说,使用TCP/IP面向连接的分层协议,克服物理线路传输数据的不可靠性。对局域的分布式系统,很少使用分层协议,而是采用较简单的模式。这种模式能取得更高的性能。在这种消息传递系统中,关于通信原语,我们讨论了阻塞与非阳塞、有缓冲区与无缓冲区、可靠与不可靠等等。在RPC进程通信模式中,机器上运行的客户进程调用在另台机器上的过程。运行系统嵌入在存根的过程库中,用来收集参数、建立消息并与内核一起建立一个实际的传递接口。问题:服务器必须被正确定位;指针与语复杂的数据结构难以传递;全局变量很难使用;很难有精确的RPC义,因为客户与服务器都有可能崩溃。RPC只能用于一个服务器与一个客户通信。当有多个处理器时,就需要另外的通信机制:组通信。ISIS提出了各种不同的组通信原语,其中最重要的是CBCAST。作业:p84,(4)、(8)、(10)、(14)、(19)、(21)

1 / 15
下载文档,编辑使用

©2015-2020 m.777doc.com 三七文档.

备案号:鲁ICP备2024069028号-1 客服联系 QQ:2149211541

×
保存成功