数据库的“分布式”控制方法

　　数据库的事务控制问题顾名思义,分布式系统由多于一个服务器组成。这产生了一个在集中式系统中不存在的问题,因为在那里T1和T2在站点3发生冲突(站点3只有一个服务器控制全部。而在分布式系统中,需要两两个事务冲突的例子择一个控制是分配给一个站点还是多个站点。如果只分配给一个站点,称这种控制方法是“集中式的”如果多个站点共同控制,称它为“分布式”控制方法。

　　知识点1：这些方法的变体也是有可能的。例如,在集中式控制方法中,可以有一个围定的站点经常作为控制的中心或者将控制分配给一个站点,过段时间再给另一个站点。虽然不同的站点可能成为控制的中心,但在系统中任何一个给定的时间,只有一个控制位,在分布式控制中,可以将所有的也或者仅仅一部分站点置入控制死锁的过程中。

　　知识点2：接下来将试论每个这些可选方案与每个算法相结合的行生物。分布式死锁预防分布式系统中的死锁预防实现起来跟在集中式系统中的实现方式实际上是相同的的。事务需要的所有资源,这里指的事务是全局事务,在它开始工作之前必须被加锁。对于分布式的死锁处理选择,事务进入系统的站点成为控制位。

　　知识点3：由于事务在全部锁请求没有确定之前并没有真正地开始运行,因此死锁被控制。在集中式死锁预防里提到的所有问题在分布式系统中依然存在。另外,由于一个事务所需的资源潜在地存储在不同的数据库、服务器不同的站点上,由于通信的延迟,需要一段较长的时间去完成预处理。较长时间等待的个副作用是容易增加大的长事务对于饥饿的敏感度。

　　知识点4：除此之外,分布式死锁预防的实现就相当直接了。事务所需要的数据所在的服务器收到控制位的通知,去锁定这些数据项。控制位要等待,一直到它确认所有的数据项已经被银才开始运行事务。如果发生站点错误或者通信错误,很有可能一个或者者更多的站点是不可用的。

　　知识点5：在这种情况下,在所有发生错误的站点或者通信线路得到修复之前,事务无法开始显然,控制位在等待的过程中也可能发生错误,这使该处理方法变得更加复杂。考这样一种情况,控制位在锁处理发生之后后发生了错误。那么所有被加锁的数据项必须释这些锁,但是在这些站点无法联系上控制位之前它们只有等待。这便是众所周知的一个受大的问题称为阻塞。

　　小编结语：其实我们在考虑到这个问题,如果一个站点错误或者通信错误发生,那么控制位有可能阻塞其他站点,其他站点也可能会阻塞控制位。我们将在下一届的教程中讨论如何去处这种阻塞特性和其他死锁算法。