悲观锁_浅谈数据库乐观锁、悲观锁

来自&＃xff1a;非科班的科班

并发问题

当程序中出现并发的问题时&＃xff0c;我们就要有相应的手段保证数据的正确性&＃xff0c;防止多个用户在操作数据的时候&＃xff0c;出现和预期数据不一样的现象&＃xff0c;产生脏数据&＃xff0c;在数据库的层面如果没有做好并发控制&＃xff0c;就可能导致脏读、幻读和不可重复读等问题&＃xff0c;所以对于并发场景锁机制的应用是非常有效的&＃xff0c;保证了数据的准确性。

以上的图就表示了并发场景时&＃xff0c;在没有锁机制的情况下&＃xff0c;产生不正确的数据&＃xff0c;与预期的数据并不符合。实现并发控制的主要手段大致可以悲观锁和乐观锁。无论是悲观锁还是乐观锁&＃xff0c;都是人们定义出来的概念&＃xff0c;可以认为是一种思想。

悲观锁

当我们要对一个数据库中的一条数据进行修改的时候&＃xff0c;为了避免同时被其他人修改&＃xff0c;最好的办法就是直接对该数据进行加锁以防止并发。这种借助数据库锁机制&＃xff0c;在修改数据之前先锁定&＃xff0c;再修改的方式被称之为悲观并发控制(又名“悲观锁”&＃xff0c;Pessimistic Concurrency Control&＃xff0c;缩写“PCC”)。

这样别的线程读取该数据的时候就需要等待当前线程释放锁&＃xff0c;获得到锁的线程才能获得该数据的读写权限。从而保证了并发修改数据错误的问题。但是由于阻塞原因&＃xff0c;所以导致吞吐量不高。悲观锁更适用于多写少读的情况。

当某一天&＃xff0c;你的好友A说要给你转账1000块&＃xff0c;好友B又说给你转账1000块。啥&＃xff1f;天上掉馅饼了吗&＃xff1f;他们进行了下面的操作&＃xff1a;

1. 好友A和好友B同时来到银行&＃xff0c;首先好友A获取到你的余额为0&＃xff0c;太穷了。

2. 好友B此时获取不到你的余额&＃xff0c;因此好友B处于阻塞状态&＃xff0c;等待ing…….。

3. 好友A给你的银行账号里面汇入1000块&＃xff0c;总额等于money&＃61;money&＃43;1000。

4. 好友A操作完&＃xff0c;此时好友B获取到你的余额1000块&＃xff0c;然后执行转账操作money&＃61;money&＃43;1000&＃xff0c;最后你的余额为2000。

假设转账的过程没有锁机制

1. 好友A和好友B同时来到银行&＃xff0c;首先好友A获取到你的余额为0&＃xff0c;太穷了。

2. 好友B此时也获取到你的余额为0&＃xff0c;然后给你转账1000&＃xff0c;总额度变为0&＃43;1000&＃61;1000。

3. 好友A也给你转账1000&＃xff0c;总额度变为还是为1000&＃xff0c;这结果肯定是不对的。

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

即使使用了悲观锁&＃xff0c;还是存在问题&＃xff0c;由于悲观锁使所有的访问者同步进行&＃xff0c;大量的访问就会阻塞&＃xff0c;占用系统资源&＃xff0c;最后的结果不可料想。此时乐观锁的作用就诞生了。

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

拿比较常用的MySql Innodb引擎举例&＃xff0c;来说明一下在SQL中如何使用悲观锁。要使用悲观锁&＃xff0c;我们必须关闭MySQL数据库的自动提交属性。因为MySQL默认使用autocommit模式(自动提交事务)&＃xff0c;也就是说&＃xff0c;当我们执行一个更新操作后&＃xff0c;MySQL会立刻将结果进行提交。

sql语句&＃xff1a;set autocommit&＃61;0


以网购扣减库存来说明一下悲观锁的使用&＃xff1a;

//开启事务
begin&＃xff1b;
select quantity from goods where id&＃61;1 for update&＃xff1b;
update goods set quantity&＃61;2 where id &＃61;1;
//提交事务
commit;


以上&＃xff0c;在对id &＃61; 1的记录修改前&＃xff0c;先通过for update的方式进行加锁&＃xff0c;然后再进行修改。如果以上修改库存的代码发生并发&＃xff0c;同一时间只有一个线程可以开启事务并获得id&＃61;1的锁&＃xff0c;其它的事务必须等本次事务提交之后才能执行。这样我们可以保证当前的数据不会被其它事务修改。

上面我们提到&＃xff0c;使用select…for update会把数据给锁住&＃xff0c;不过我们需要注意一些锁的级别&＃xff0c;MySQL InnoDB默认行级锁。行级锁都是基于索引的&＃xff0c;如果一条SQL语句用不到索引是不会使用行级锁的&＃xff0c;会使用表锁。

乐观锁

乐观锁( Optimistic Locking ) 相对悲观锁而言&＃xff0c;乐观锁假设认为数据一般情况下不会造成冲突&＃xff0c;所以在数据进行提交更新的时候&＃xff0c;才会正式对数据的冲突与否进行检测&＃xff0c;如果发现冲突了&＃xff0c;则让返回用户错误的信息&＃xff0c;让用户决定如何去做。由于乐观锁没有了锁等待&＃xff0c;提高了吞吐量&＃xff0c;所以乐观锁适合多读少写的场景。 常见的乐观锁实现方式是&＃xff1a;版本号version和CAS。

采用上面的例子&＃xff0c;使用乐观锁加版本号的方式&＃xff0c;给数据库的表增加一个字段version版本号&＃xff0c;执行的操作如下&＃xff1a;

• 你的好友A获取你的余额为0并获取当前的版本号version&＃61;0。

• 好友B也同时获取你的余额为0并获取当前的版本号version&＃61;0。

• 好好友A转账后的总额为1000&＃xff0c;并使版本号version&＃43;1&＃61;1。更新到数据库中。

• 好友B同时也将金额1000汇进你的账号中&＃xff0c;并使版本号version&＃43;1&＃61;1&＃xff0c;提交事务的时候&＃xff0c;发现版本号已被修改&＃xff0c;提交事务失败&＃xff0c;更新不成功。

• 此时好友B需要再次执行转账操作&＃xff0c;才能给你转账成功。

相对于悲观锁&＃xff0c;在对数据库进行处理的时候&＃xff0c;乐观锁并不会使用数据库提供的锁机制。一般的实现乐观锁的方式就是记录数据版本。数据版本,为数据增加的一个版本标识。当读取数据时&＃xff0c;将版本标识的值一同读出&＃xff0c;数据每更新一次&＃xff0c;同时对版本标识进行更新。当我们提交更新的时候&＃xff0c;判断数据库表对应记录的当前版本信息与第一次取出来的版本标识进行比对&＃xff0c;如果数据库表当前版本号与第一次取出来的版本标识值相等&＃xff0c;则予以更新&＃xff0c;否则认为是过期数据。

使用乐观锁就不需要借助数据库的锁机制了。乐观锁的概念中其实已经阐述了它的具体实现细节。主要就是两个步骤&＃xff1a;冲突检测和数据更新。其实现方式有一种比较典型的就是CAS。

CAS是项乐观锁技术&＃xff0c;当多个线程尝试使用CAS同时更新同一个变量时&＃xff0c;只有其中一个线程能更新变量的值&＃xff0c;而其它线程都失败&＃xff0c;失败的线程并不会被挂起&＃xff0c;而是被告知这次竞争中失败&＃xff0c;并可以再次尝试。

特别推荐一个分享架构&＃43;算法的优质内容&＃xff0c;还没关注的小伙伴&＃xff0c;可以长按关注一下&＃xff1a;

长按订阅更多精彩▼

如有收获&＃xff0c;点个在看&＃xff0c;诚挚感谢