分布式系统的同步续.pptVIP

陈香兰@2007.3.21分布式系统同步（续）*在图g中，γ修改了文件并已提交。这一次β仍必须被中止。在图h中γ正在修改文件，尽管它还未被提交，但β还是开始太早仍必须中止。陈香兰@2007.3.21分布式系统同步（续）*优化方法2（cont’d）通过私有索引，文件可以按通常的方式读取，因为索引中包含有文件开始几个块

的磁盘地址。当文件第一次被修改时，将生成该

块的拷贝，其地址也将被插入索引

中，如图。然后就可以在不影响原

始块的情况下更新这个块。添加块也是用这个方法解决的。新

块有时也称作影像块

（Shadowblock）。陈香兰@2007.3.21分布式系统同步（续）*优化方法2（cont’d）在上图中，运行事务的进程看到了被修改的文件，但其他进程看到的仍是原来的文件。在更复杂的事务中，私有工作空间可能

包含了大量的文件而不仅仅是一个。若事务异常中止，那么私有工作空间

就会被删除，它所指向的所有私有块

也将被释放回自由列表中。若事务成功结束，那么私有索引将被

自动移到父辈的工作区中，如图。不

需要的块将它放回自由列表中陈香兰@2007.3.21分布式系统同步（续）*2、写前日志另一个实现事务的常用方法是写前日志（writeheadlog）。有时也称为计划列表（intentionslist）。使用这种方法时，文件将真正修改，但是在改动任何块之前，将一条记录写入稳定存储器的写前日志中，以判断是哪一个事务在进行修改操作，哪一个文件的哪一块被改动了，旧值和新值分别是什么。只有当日志成功写入之后才可以进行文件的修改。陈香兰@2007.3.21分布式系统同步（续）*日志工作举例这是一个使用两个初值均是0的共享变量（或其他对象）x，y的简单事务。对事务中三条语句中的每一条，在执行之前都要写入一条日志，以记录新值和旧值，他们用斜杠来区分。陈香兰@2007.3.21分布式系统同步（续）*日志工作举例（cont’d）三个记录依次写入日志：如果事务执行成功且被提交，那么它的提交记录也将被写入日志，但数据不需要变动，因为它们已经被更新了。陈香兰@2007.3.21分布式系统同步（续）*使用日志进行系统恢复（1）使用日志使得事务向前（处理事务）和向后（撤销事务）成为了可能。若事务异常中止，可用日志来备份初始状态。从日志的末尾开始向回读取每条记录，再将记录中描述的改动复原。这个操作称之为滚回。陈香兰@2007.3.21分布式系统同步（续）*使用日志进行系统恢复（2）日志也可用来进行系统崩溃后的恢复。假设执行事务的进程在写入上例最后一条记录后及改变x之前崩溃。在机器重启动后，日志可以用来检查在系统崩溃时刻是否有事务正在处理中。当读到最后一条记录显示x的当前值是1，那么说明崩溃显然是在更新之前发生的，所以x的值应被改为4。相反，如果在系统恢复时x的值是4，那么同样也清楚的说明崩溃是在更新后发生的，因此不需要进行任何变动。陈香兰@2007.3.21分布式系统同步（续）*事务提交事务提交操作必须是原子的，即瞬时的和不可再分的。在分布式系统中，提交操作可能需要不同机器上的多个进程的协作，这些进程中的每一个都有一些被事务改动过的变量、文件、数据库或者其他对象。本节将研究一个在分布式系统中实现原子性提交的协议。陈香兰@2007.3.21分布式系统同步（续）*两阶段提交协议two-phasecommitprotocol（Gray，1978）尽管它不是此类协议中唯一的一个，但它却是使用最广泛的一个基本思想：进程中的某一个将起到协调者的作用。一般来说这个进程就是执行事务的进程。提交协议开始时协调者先写入一条日志条目以表明它要开始提交协议，然后它给每个相关进程（下属）发送一条消息通知它们为提交作好准备。陈香兰@2007.3.21分布式系统同步（续）*当一个下属收到消息后，它先进行检查以确认是否为提交作好了准备，然后将它的决定发回给协调者。当协调者收到了所有的响应后，它就知道是否可以提交或中止。如果所有的进程都准备提交，那么事务就可以提交了。如果一个或几个进程不能提交（或没有响应），那么事务就得中止。无论哪种情况，协调者都要写一条日志记录并给每个下属发送一条消息以便将决定通知它们。正是因为写入的日志才使得事务真正被提交，并且无论发生什么它都会继续下去。陈香兰@2007.3.21分布式系统同步（续）*陈香兰@2007.3.21分布式系统同步（续）*崩溃和恢复由于使用了稳定存储器上的日志，所以这个协议在（多个）崩溃面前仍然是很有弹性的。如果协调者在写入了初始化日志后崩溃，那么在