汽车销售合同Title.ppt

分布式系统同步（续） 2、死锁检测与消除 死锁检测与恢复算法比较流行，原因是预防算法和避免算法太难了。我们将讨论几种用于死锁检测的算法。 尽管比在单处理机系统中困难得多，但是死锁预防还是能够实现的。在原子事务提出之后，死锁的预防便成为可能。后面将讨论两种算法。 3、死锁的预防 第六十二页，共八十九页。 分布式系统同步（续） 4、死锁的避免 死锁避免在分布式系统中从来都不采用。 既然在单处理机系统中都不采用死锁避免机制，那么在更复杂的分布式系统中我们又何必采用呢？ 该方法的问题在于银行家算法和类似算法需要（事先）知道每个进程最终到底需要多少资源。而这样的信息即使有也非常的少。 因此关于分布式系统中的死锁问题的讨论将只集中于两种技术：死锁检测和死锁预防。 第六十三页，共八十九页。 分布式系统同步（续） 3.5.1 分布式死锁检测 在一些分布式系统中原子事务的提出使得在死锁可以得到解决。 在一般操作系统中，在检测到死锁后，解决的方法是中止一个或几个进程，但这必然会使一些用户感到不满。 在基于原子事务的系统中检测到死锁后，解决方法是中止掉一个或几个事务。由于事务允许出现中止，不会导致用户不满，也不会导致系统出现其他后果，例如数据不一致等等。 第六十四页，共八十九页。 分布式系统同步（续） 当一个事务因为产生死锁而被中止的时候， 首先让系统恢复到事务开始前的状态，然后事务可以从这一点重新开始。 若运气好，事务在第二次执行时就能成功完成。 使用事务与不使用事务的差别在于使用事务时中止一个事务的后果要比不使用事务时终止一个进程的后果小的多。 第六十五页，共八十九页。 分布式系统同步（续） 事务举例 考虑到合肥火车站买一张从合肥到长沙的座票。由于没有直达火车，只能买联票。合肥?阜阳；阜阳?武汉；武汉?长沙。下面通过3个操作预定了这3条独立的路线的座票。 BEGIN_TRANSACTION reserve 合肥-阜阳 reserve 阜阳-武汉 reserve 武汉-长沙 END_TRANSACTION 第三十页，共八十九页。 分布式系统同步（续） 事务举例（cont’d） 现在假设前两条路线已经预定成功，但是第三条已经定满了。那么事务就会因此而中止，前两个预定的结果也将被取消——售票系统的数据库恢复到了事务开始前的状态，就像什么也没有发生一样。 BEGIN_TRANSACTION reserve 合肥-阜阳 reserve 阜阳-武汉 武汉-长沙 已满?ABORT_TRANSACTION 第三十一页，共八十九页。 分布式系统同步（续） 3、事务的特性 事务有四个重要的特性，它们是： 原子性（Atomic）：对外部世界来说，事务的发生是不可分割的； 一致性（Consistent）：事务不会破坏系统的恒定； 孤立性（Isolated）：并发的事务不会互相干扰； 持久性（Durable）：一旦一个事务提交，改变就是永远存在的。 这几个属性通常按其字母简称为ACID。 第三十二页，共八十九页。 分布式系统同步（续） 1）事务的原子性 所有事务具有的第一个特性是原子性。 这个特性确保了每个事务要么全部发生，要么全部不发生。如果发生，就是不可分割的瞬间的操作。 当一个事务处在处理过程中，其他进程（无论是否与事务有关）都不能看到任何中间状态。 第三十三页，共八十九页。 分布式系统同步（续） 2）事务的一致性 第二个特性说明事务是一致的。 这意味着系统拥有某种必须保持的不变性，一旦在事务开始之前有这样的性质，则事务结束后该性质还应该存在。 例如在一个银行系统中，最关键的不变性是资金守恒规则。在任何内部转帐之后，银行的资金账目应与转帐前保持一致，但是在事务执行的短暂时刻内，这种不变性会改变。但是，事务结束之后，这种改变就不存在了。 第三十四页，共八十九页。 分布式系统同步（续） 3）事务的孤立性 第三个特性说明事务是孤立的。 这意味着如果两个或两个以上的事务在同时运行，那么对它们自己和其他进程来说，最终结果看起来就像是所有的事务是按某种次序（依赖于系统）顺序运行的。 第三十五页，共八十九页。 分布式系统同步（续） 4）事务的持久性 第四个特性说明事务是持久的。 即一旦事务提交，无论发生什么，这个事务都会向前进行，结果不会再变了。提交之后发生的任何错误都不可能将结果取消或导致结果丢失。 第三十六页，共八十九页。 分布式系统同步（续） 4、嵌套事务 事务可以包含子事务，这通常称作嵌套事务。 顶层事务可以在不同的处理机上创建并运行子事务，以提高性能简化编程。 这些子事务中的任何一个都可以执行一个或多个子事务，或者创建自己的子事务。 子事务会引起持久性问题。 假设一个事务启动了几个并行的子事务，其中一个已经提交，并使自己的结果