在关系型数据库中,悲观锁与乐观锁是解决资源并发场景的解决方案,接下来将详细讲解?一下这两个并发解决方案的实际使用及优缺点。
首先定义一下数据库,做一个最简单的库存表,如下设计:
|
|
quantity
代表着不同商品 oid 的库存,接下来 OCC 及 PCC 使用此数据库进行演示。
它假设多用户并发的事务在处理时不会彼此互相影响,各事务能够在不产生锁的情况下处理各自影响的那部分数据。在提交数据更新之前,每个事务会先检查在该事务读取数据后,有没有其他事务又修改了该数据。如果其他事务有更新的话,正在提交的事务会进行回滚。
即“乐观锁?”认为拿锁的用户多半是会成功的,因此在进行完业务操作需要实际更新数据的最后一步再去拿一下锁就好。这样就可以避免使用数据库自身定义的行锁,可以避免死锁现象的产生。
|
|
乐观并发控制多数用于数据争用不大、冲突较少的环境中,这种环境中,偶尔回滚事务的成本会低于读取数据时锁定数据的成本,因此可以获得比其他并发控制方法更高的吞吐量。
它可以阻止一个事务以影响其他用户的方式来修改数据。如果一个事务执行的操作读某行数据应用了锁,那只有当这个事务把锁释放,其他事务才能够执行与该锁冲突的操作。
这种设计采用了“一锁二查三更新”模式,就是采用数据库中自带 select ... for update
关键字进行对当前事务添加行级锁? 先将要操作的数据进行锁上,之后执行对应查询数据并执行更新操作。
|
|
MySQL还有个问题是select ... for update
语句执行中所有扫描过的行都会被锁上,这一点很容易造成问题。因此如果在MySQL中用悲观锁务必要确定走了索引,而不是全表扫描。
悲观并发控制主要用于数据争用激烈的环境,以及发生并发冲突时使用锁保护数据的成本要低于回滚事务的成本的环境中。
【优点】
data race
)的概率是比较小的,因此尽可能直接做下去,直到提交的时候才去锁定,所以不会产生任何锁和死锁;【缺点】
【优点】
【缺点】