事务的并发控制

 事务的并发控制

 

9．1 

信号量：依赖于程序员；不适当的使

用会死锁。分布式环境中很难

实现，必须保持信号量数据的绝对一

致性。

 

管程：编译器支持的编程语言结构。

编译器依靠共享内存实现信号量，没

有共享内存，就不能使用管程。

 

对事务的调度要保证对共享数据

的执行效果与其串行调度等价，

服务器可通过串行访问数据项来

实现串行等价。

 

锁：串行结构的实现

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

可串行性（化）：两个事务的全部

冲突操作对应相同的顺序执行。

为保证可串行性，常用的三种并发

控制方法：加锁、乐观并发控

制、时间戳定序。

 

    1  加锁：

当事务完成时解锁，当一数据项

被加锁，则只有加锁的事务可访

问它，其它事务或者等待锁被解

开，或者在某种情况下共享锁。

使用锁会导致死锁，即事务彼

此等待解锁。

    2  乐观法：

事务执行到提交前，在允许提交

前，服务器完成一个检查，发现

已完成的操作是否与相同数据项

上的其它并发事务的操作发生

冲突，若冲突，服务器终止它。

    3  时间戳定序：

服务器记录读写每个数据项的最

近时间，且对每一操作，要比较

事务的时间戳和数据项的时间戳，

以决定操作是否可立即执行、

或被延迟、被拒绝。

9．2  锁机制

 

读    读                   不冲突

读    写                   冲突

写    写                   冲突

 

1              读锁：其它可读，但不能写，

有一个事务即加一个锁；

2              写锁：写之前获得，不能读

或写（再写）；

 

Lock  UnLock 操作

 

锁的粒度越小，加锁就可以越精确，

也就能实现更大的并行度。

同时，锁的粒度越小，就需要更多的

锁，这样开销也就越大，也

就更容易导致死锁。

 

9．3  乐观并发控制

 

基础：在大多数应用中，两客户的事务访问同一数据项的可能性很小。

 

三个阶段：

1  读出阶段：

每个事务修改的每个数据项都有一个试用性版本，所有的读操作都

是在数据项的提交版本上完成的，不会读出“脏”数据。

    2  验证阶段：

当接到Close Transaction请求，就检验事务是否存在对数据项上的操作与其它事务在同一数据项上的操作发生冲突，若验证通

过，则事务提交，若验证失败，则要采用某种形式的冲突解决策略。

    3  写入阶段：

若事务通过验证，它的试用性质版本中的所有修改记录将设置成永久的。

 

事务验证即验证采用读/写冲突规则保证其特定事务的调度关于

所有其他的重叠事务是串行等价的。

 

事务验证：是基于一对事务Ti和Tj的操作间冲突的，事务Tj关

于一个重叠事务Ti是可串行化的，那么它们的操作必须遵守以

下规则。

 

 

优点：避免了死锁，允许最大的并行度。

缺点：有时会失效，所有的事务都必须退回重新运行一遍。

在重负载的情况下，比较严重。

 

 

9．4  时间戳定序

每个事务开始时都被分配了一个唯一的时间戳，来自事务的申请

就可以根据它们的时间戳获得一个全序。

服务器可以用自己的时钟来分配时间戳，或者它可采用当分配时

间戳时就加1的计数器——“伪时间”。

 

优点：不会出现死锁。

缺点：在于实现的复杂性，这将导致降低性能。

  硬件、系统和语言对并发支持的总结

第十章  分布式事务

 

事务的ACID特性：

 

原子性

一致性

独立性

持久性

 

分布式事务：其活动涉及多个服务器的事务；

嵌套事务：间接涉及多个服务器的客户事务；

 

每个服务器对其本地数据实行本地并发控制，以保证事务在本地可串行，分布式事务必须在全局可串行。

在某些情况下，事务在本地服务器上是串行的，但同时可以发生不同服务器间的依赖循环，从而导致死锁。

 

分布式事务的协调者

事务的第一个服务器成为事务的协调者，负责终止或提交事务，以

及增加其他被称为参与者的服务器，协调者管理着一个参与者表列，

而每个参与者都记录了协调者服务器的标识。

 

 

原子提交协议：

 

 

两阶段提交协议

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

两阶段提交协议中的超时

若协调者失败了，则参与者不能获得应答直到协调者重新启动，这

会导致参与者处于不确定状态的额外延迟。

 

当客户发送了close transaction给协调者，参与者只能检测到这种

情况：长时间没有特定事务的请求。

由于在这个时期没有作出决定，参与者可在一段时间后单向决定

终止。

 

事务实现中的问题：

（1） 预读写

如果一个事务对一个数据进行读操作，而这个数据正在被其他将要

退出的事务操作，这时预读问题就发生了。

 

 

 

如果一个事务对一个数据进行写操作，而这个数据正在被另一个事务操作，预写问题。

 

涉及到独立事务的相互作用。

事务管理服务采用延迟执行就可以避免这些问题的发生。

延迟执行使得正在被事务操作的数据不能被其他事务读写，直到当

前事务进入提交阶段或者中途退出。

 

延迟会降低系统的性能。

 

（2） 中途退出（domino effect）

如果其他事务看到了与退出的事务有关的结果，这个事务的

退出可能遭受domino effect。

 

任何以预写的数据为执行基础的事务在预写的事务中途退出后，也都必须退出。

 

（3） 保证恢复能力

如果另一个未完成的提交请求涉及到相同的数据，则应延迟当前的提交。

 

暂时拷贝可以保存在本地的易失存储器中，如果一直不进入提交阶

段，则删除暂时拷贝。如果进入提交阶段，则把暂时拷贝复制到永

久的不易丢失的存储器中。

 

 

 

 

分布式事务的并发控制

（1）分布式事务的锁机制

由于服务器彼此独立地设置它们的锁，有可能不同服务器将不同的次序加于事务之上，在这种情况下，这些不同次序会导致事务间的循环依赖，出现分布式死锁情况。

在嵌套事务中，为了避免层次间的潜在冲突，父事务不允许与它们的子事务并发执行。嵌套事务从它们的祖先那里继承锁。

对一个获得数据资源读锁的嵌套事务，该数据资源写锁的持有者必须是它的祖先。当一个嵌套事务提交时，它的锁被其父母继承。当嵌套事务中止时，它的锁被解除。

 

（2）分布式事务的时间戳定序

为实现在所有服务器上的相同次序，服务器必须在它们的时间戳次序上达成一致。

在分布式系统中，要求每一个事务可以分配到环境中唯一的时间戳。该事务在调用其他服务器的资源时，同样也把该时间戳发送给相应的服务器，以使该服务器对事务进行合理的调度。分布式系统中的服务器共同负责保证它们按与串行效果等价的方式完成。

但是时间戳的分配还存在着一致性的问题。一个分布式系统包含很多不同的地点和个别的计算机系统，每一个地点和系统都有其各自的本地时间，各处系统的时钟也会偏移。因此各个服务器间的时钟可能不同步，从而造成时间戳分配的不一致性。为了保证事务次序同在实际时间中开始的次序一致，通常采用同步本地物理时钟的方法。

 

 

（3）分布式事务的乐观并发控制

服务器在验证开始时，分配事务号，事务根据事务号的次序排序。分布式事务被一组相互独立的服务器集验证，每个服务器验证访问其数据项的事务。所有服务器的验证发生在两阶段提交协议的第一阶段。

 

 

分布式死锁

超时 解除死锁。

寻找事务等待图中的环路来实现。

 

死锁检测方案

 

伪死锁

 

带复制数据的事务

事务服务器上的数据项可被复制，以提高可用性和其他性能。

 

单副本可串行性：事务在各客户的复制数据项上执行的效果仿佛是

他们一次只对单个数据项执行。

 

Read one/ write all

读操作只由单个复制管理者执行，而写操作则由所有的复制管理者

执行。

它不是一个实用的方案，因为当某些复制管理者失效时，它无法运行，设计有效副本方案，用来允许一些复制管理者暂时失效。

其策略是：客户的请求可由任一有效复制者执行，而客户的更新请求必须由包含该数据项副本的组中所有有效复制者执行。