数据库分布式的死锁的解决方法

　　在之前，我们已经了解过了分布式的数据库死锁的问题了，那么对于分布式死锁避免分布式死锁避免可以使用之前讨论过的集中式死锁避免的两个可选方案之一。

　　知识点1：等待-死亡算法和分布式伤害-等待算法与集中式中的算法从本质上来说是相同的。主要的区别正如前文所说,需要处理事务的站点问题和事务的控制问题,因为每个事务可能在多个站点执行它的工作,一个给定的事务可能与相同站点的其他事务或者不同站点的不同事务发生冲突。当冲突发生时,中突中的一个或者多个事务有可能处于非活动状态。

　　知识点2：分布式等待-死亡算法正如前面提到的,在分布式系统中的等待-死亡的基本算法跟在集中式系统中的算法实际上一样的。当两个事务间发生冲突时,其实，我们可以用计算机计算年龄(基于全局时间藏)来决定哪个事务被杀死,算法声明如果一个较年轻的事务请求锁操作,但该数据项已经被另一个较老的事务加过锁,那么较年轻事务将死亡,如果使用者仍然希望该事务运行,那么它将在之后带着与现在相同的时间戳重生。另一方面,如果一个较老的事务请求锁操作,但该数据项已经被一个较年轻的事务加过锁,那么较老的事务将等待。在分布式系统中实现这个算法有两个问题。

　　知识点3：其实我们之前解释了事务站点问题。我们将在例子中解释分布式等待-死亡算法的事务控制问题,并结合分布式伤害-等特待算法进行让我们假定事务“Ta”位于站点K,Ta想要去锁定位于K的数据项“X当Ta到达站点K的时候,假定事务“Tb”已经独占了x。当冲突发生的时候,需要比较Ta和Tb的年龄。哪个事务较老哪个事务较年轻,决定了接下来要采取的措施。需要注意的是,尽管Ta和Tb在站点K发生了冲突,但Tb很有可能在其他站点处于活动状态而在K站点是非活动的。这里存在两种情况情况1:Ta比Tb老。

　　知识点4：在这种情况下,Ta必须去等待Tb。因为Ta只在站点K活动,这种等待将完全阻碍Ta的进程。Ta只能在Tb彻底提交、取消或者决定死亡之后才能进行。Ta如何才能知道要等待多久呢?Ta要在站点K等待直到该站点收到一个消息,被告知Tb已经终止不管是成功终止还是不成功终止。切记,站点K在Tb已经访问过的站点列表中,因此,并发控制的广播中记录Tb终止的站点中将包含站点K情况2:Ta比Tb年轻。在这种情况下,Ta将不得不死亡。相同地,由于Ta只在站点K活动,位于K的并发控制将杀死Ta并且给Ta已经访问过的所有站点发送消息,告诉它们也要杀死Ta。一且Ta在所有站点终止,使用者将得到通知。

　　知识点5：分布式伤害-等待算法与集中式伤害等待算法类似,在分布式伤害-死亡算法中,当有两个事务之间发生冲突时,将使用年龄来决定哪个事务等待或者受伤害。算法表明如果一个较年轻的事务请求锁操作,但该数据项已经被另一个较老的事务加过锁,那么较年轻事务将等待较老的事务。另一方面,如果一个较老的事务请求锁操作,但该数据项已经被一个较年轻的事务加过锁,那么较老的事务将有权力通过伤害较年轻的事务而获得资源。同样,在分布式系统中实现这个算法有两个问题。

　　小编结语：其实我们对于这一些分布式的死锁办法，已经了解决的方法了，另外我们需要注意的是分布式伤害-等待算法与集中式伤害等待算法类似。感谢大家的支持。