Pessimistic and optimistic locking

事务隔离通常通过锁定任何对事务中资源的访问来实现的。总的来说,有两种方法针对事务的锁定:乐观锁(Pessimistic locking)和悲观锁(Optimistic locking)

悲观锁(Pessimistic locking)

悲观锁,正如其名,它指的是对数据被外界(包括本系统当前的其他事务,以及来自外部系统的事务处理)修改持保守态度,因此,在整个数据处理过程中,将数据处于锁定状态。悲观锁的实现,往往依靠数据库提供的锁机制 (也只有数据库层提供的锁机制才能真正保证数据访问的排他性,否则,即使在本系统中实现了加锁机制,也无法保证外部系统不会修改数据)。

悲观锁的缺点在于,资源第一次的访问就会被事务锁定,除非事务完成,资源始终是不可访问的。如果大量事务都是仅仅对事务进行检索而不是更新操作,那么这种排它锁会大量阻塞,引起锁的争用。这种情况下,乐观锁会是一种更好的方案。在使用悲观锁的情况下,是通过请求失败来保证并发安全性的。以银行系统为例,一旦一个账户通过事务来访问,那么就会锁定整个账户。其他的事务尝试访问账户都会被延迟,阻塞,直到之前的事务结束(完成或者回滚)。悲观锁会一直存在,直到事务提交或者回滚。

乐观锁( Optimistic Locking )

乐观锁( Optimistic Locking ) 相对悲观锁而言,乐观锁假设认为数据一般情况下不会造成冲突,所以在数据进行提交更新的时候,才会正式对数据的冲突与否进行检测,如果发现冲突了,则让返回用户错误的信息,让用户决定如何去做。那么我们如何实现乐观锁呢,一般来说有以下2种方式:

在使用乐观锁的时候,资源并不会在第一次由事务访问的时候就锁定,相反,资源的状态会使用悲观锁的方式锁定。当其他事务并发的访问资源,并且访问资源的时候,是可能出现冲突的。当提交的时候,资源将要持久化到存储的时候,会重新读取资源的状态,然后对比事务第一次访问的时候所锁定的状态,如果两个状态不同,就会有冲突,从而事务会回滚。

同样以银行应用为例,账户第一次由事务访问的时候,就记录了账户的余额。当事务修改了账户的余额的时候,账户的信息会在执行更新之前再次查询账户的余额。如果余额在事务期间有变化,那么事务就会失败,如果余额没有变化,那么这次修改就会被持久化到存储中。

乐观并发控制(Optimistic concurrency control)

乐观并发控制(OCC)是一种应用到事务系统中的并发控制方法,比如在关系数据库管理系统以及软件事务内存等。OCC的理论依据是多数事务在执行更新的时候,是不会影响到彼此的。在运行时,事务使用资源是不需要获取资源的锁的,但是在提交之前,每个事务都会验证并没有其他的事务在修改数据。如果检查碰到了更新冲突,那么事务的提交会回滚,然后重新执行。

前面提到了OCC的理论依据,所以OCC一般用于低数据冲突的环境。当争用很少的时候,事务就能够几乎不需要付出管理锁的代价,也不需要等待其他事务完成了。这样可以比其它并发控制带来更高的吞吐。当然了,如果数据资源频繁出现争用的话,那么事务的重启就会严重的影响性能了。这个时候使用其他并发控制可能更好。然而,基于锁的方法(悲观锁)在锁定数据的时候,会严重限制并发性能。