分布式系统课件：Chapter 6 Synchronization.pptVIP

分布式死锁预防 打破四个必要条件中的一个。 分布式系统中的死锁 * * 一个事务释放锁的时候可能还没有提交，结果可能是一个中间状态。如果这个时候释放锁，其他事务请求锁，则其他事务会看到这个中间结果，导致不一致。 例如银行系统中转账过程中。。。 加锁法实现 用一个集中式的加锁管理者来实现; 每台机器上有一个本地加锁管理者管理本地文件。 两种情况下，加锁管理者都拥有一个锁定的文件列表，所有欲对已加锁文件进行的加锁尝试都将被拒绝。 读锁和写锁 上述方案限制过于严格，可以通过区分读锁和写锁来加以改进： 如果在一个文件上设置了读锁，那么在它上面设置其他的读锁也是允许的； 读锁用来确保文件不会被改写（也即排斥所有的写入者），但不禁止其他读取文件的事务； 当一个文件被设置写锁时，其他任何类型的锁都被禁止。 读锁共享，写锁互斥。 锁的粒度 加锁单位的大小称为锁的粒度。例如：整个文件、记录、页面，或整个数据库； 粒度越合适，加锁就可以越精确，也就能实现更大的并发度；例如，允许两个进程同时对某个文件的开头和末尾进行操作； 锁分得越细致，就需要更多的锁，开销也就越大，也容易导致死锁； Two-Phase Locking (1) 两段锁（Two-Phase Locking，简称2PL）协议是保证并发调度可串行性的封锁协议，它提供了一种可以串行调度的算法。 在两阶段加锁法中，进程在增长阶段先请求它需要的所有锁，然后在收缩阶段释放它们。 Two-Phase Locking (1) 遵守三个规则: 当调度管理器收到来自事务管理器的oper(T,x)操作时, 检测该操作是否与已经允许锁定的另一个进程冲突？如果是, oper(T,x)被延迟；否则，它就允许对数据项x加锁, 并将oper(T,x)传递给数据管理器； 直到数据管理器通知它已经完成了对锁定数据项x的操作, 调度管理器才会释放数据项x的锁； 一旦调度管理器为事务T释放了锁，那么无论事务T请求为哪个数据项加锁, 调度管理器都不会允许T加另外一把锁。T获取另外一把锁的任何企图都是一个程序错误, 都会中止事务T. Two-Phase Locking (1) 可以证明（Eswaran等，1976）如果所有的事务都使用两阶段加锁法，那么通过交错事务进行的所有调度都是串行的。 在紧偶合系统中两阶段加锁法被广泛使用。 Two-Phase Locking (1) 严格的两阶段加锁法：收缩阶段是在事务结束运行之后要么提交，要么中止时出现。 Strict two-phase locking. Two-Phase Locking (1) 该策略有2个优点： 一个事务总是读由另一个已提交的事务写入的值，不会因为一个事务的计算是基于它本不应该看到的文件而中止它； 所有锁的请求与释放都可以由系统来处理而无须事务关心：只要访问一个文件就可以请求一个锁，当事务结束时就可以释放一个锁。 该策略消除了瀑布型中止：不得不撤销一个已经提交的事务，因为它看到了不该看到的文件。 死锁 加锁，即使两阶段加锁，也可能会导致死锁。例如：若两个进程都试图以相反的顺序请求同一对锁，那么就会发生死锁。 解决方法： 采用诸如以某种规范顺序请求所有的锁之类的一般方法来防止保持-等待循环的出现。 通过对一张精确描述哪个进程可以拥有哪个锁，它还想请求哪个锁的图进行死锁扫描，以检查是否有环路出现，也可以防止死锁。 如果事先知道一个锁的拥有时间不会超过T秒时，也可以采用一个超时方案：如果某个拥有者连续拥有同一个锁超过了T秒，那么一定是出现了死锁。 2、乐观的并发控制 处理同时运行多个事务的第二种方法是乐观并发控制法（Kung and Robinson，1981）。思想： 尽管放心去做你想做的，不用在意其他人正在做什么。如果有问题出现，那么以后再考虑吧。 在实际情况中，冲突相对来说非常少，所以这个策略大部分时间都可以正常工作。 乐观的并发控制 冲突的处理： 记录下有哪些文件曾经被读写过； 在提交时刻，检测其他的事务以判断在本事务开始后它的文件是否被其他事务修改过？ 如果被修改过，那么本事务将被中止； 如果没有修改过，那么本事务就可以提交了。 乐观的并发控制 最适合于基于私有工作空间的情况： 每个事务都独立地修改各自的文件，不会涉及其他的事务； 在结束的时候，新的文件要么被提交要么被释放。 优点： 避免了死锁，而且允许最大的并行度（进程不需要去等待一个锁）； 缺点： 有时可能会失效，这时所有事务都必须退回重新运行； 在重负载的情况下，算法失效的可能性将会直线上升，这使得乐观并发控制算法成了一个很糟糕的选择。 3、时间戳 在一个事务开始做BEGIN_TRANSACTION的