Fork me on GitHub

乐观锁和悲观锁

乐观锁

乐观锁相对悲观锁而言,乐观锁假设认为数据一般情况下不会造成冲突,所以在数据进行提交更新的时候,才会正式对数据的冲突与否进行检测,如果发现冲突,则返回错误信息,让用户决定做什么。
相对对悲观锁,在对数据库进行处理的时候,乐观锁并不会使用数据库提供的锁机制。一般的实现乐观锁的方式就是记录数据的版本。
数据版本,为数据增加一个版本标识。当读取数据时,将版本标识的值一同读出,数据每更新一次,同时对版本标识进行更新。当我们提交更新的时候,判断数据表对应记录的当前版本信息与第一次取出来的版本标识进行比对,如果数据库当前版本号与第一次取出来的版本标识值相等,则予以更新,否则认为是过期数据。
实现数据版本的标识有两种方式:第一种是使用版本号,第二种是使用时间戳。

优点与不足

乐观并发控制相信事务之间的数据竞争的概率是比较小的,因此尽可能直接做下去,直到提交的时候才锁定,所以不会产生任何锁和死锁。但是如果简单的这么做会遇到不可预期的结果,例如两个事务都读取数据库的某一行,经过修改以后写回数据库,这时就遇到了问题。

悲观锁

在数据库中,悲观锁的流程如下:
在对任意记录进行修改前,先尝试为该记录加上排它锁。
如果加锁失败,说明该记录正在被修改,那么当前查询可能要等待或者抛出异常。具体响应方式由开发者根据实际需要决定。
如果成功加锁,那么就可以对记录做修改,事务完成后就会解锁。
其间如果有其他对该记录做修改或者加排它锁的操作,都会等待我们解锁或者直接抛出异常。

优点和不足

悲观并发控制实际上是“先取锁再访问”的保守策略,为数据处理的安全提供了保证。但是在效率方面,处理加锁机制会让数据库产生额外的开销,还有增加产生死锁的机会;另外,在只读型事务处理中由于不会产生冲突,也没有必要使用锁,这样做只能增加系统负载;还有降低了并行性,一个事务如果锁定了某行数据,其他事务就必须等待该事务处理完才可以处理那行数。

建议

如果数据被频繁地被并发事务修改建议使用悲观锁,如果不会被并发事务频繁的修改建议使用乐观锁。


最新评论

    还没有人评论...

当当

友情链接

Powered by Python. Copyright © 2017.

鄂ICP备17010875号. All rights reserved.