数据库中乐观锁、悲观锁、共享锁和排它锁的理解

mysql5.6

咱们在操做数据库的时候，可能会因为并发问题而引发的数据的不一致性（数据冲突）

乐观锁

乐观锁不是数据库自带的，须要咱们本身去实现。乐观锁是指操做数据库时(更新操做)，想法很乐观，认为此次的操做不会致使冲突，在操做数据时，并不进行任何其余的特殊处理（也就是不加锁），而在进行更新后，再去判断是否有冲突了。

一般实现是这样的：在表中的数据进行操做时(更新)，先给数据表加一个版本(version)字段，每操做一次，将那条记录的版本号加1。也就是先查询出那条记录，获取出version字段,若是要对那条记录进行操做(更新),则先判断此刻version的值是否与刚刚查询出来时的version的值相等，若是相等，则说明这段期间，没有其余程序对其进行操做，则能够执行更新，将version字段的值加1；若是更新时发现此刻的version值与刚刚获取出来的version的值不相等，则说明这段期间已经有其余程序对其进行操做了，则不进行更新操做。

举例：

下单操做包括3步骤：

1.查询出商品信息

select (status,status,version) from t_goods where id=#{id}

2.根据商品信息生成订单

3.修改商品status为2

update t_goods 

set status=2,version=version+1

where id=#{id} and version=#{version};

 

除了本身手动实现乐观锁以外，如今网上许多框架已经封装好了乐观锁的实现，如hibernate，须要时，可能自行搜索"hiberate 乐观锁"试试看。

 

悲观锁

与乐观锁相对应的就是悲观锁了。悲观锁就是在操做数据时，认为此操做会出现数据冲突，因此在进行每次操做时都要经过获取锁才能进行对相同数据的操做，这点跟java中的synchronized很类似，因此悲观锁须要耗费较多的时间。另外与乐观锁相对应的，悲观锁是由数据库本身实现了的，要用的时候，咱们直接调用数据库的相关语句就能够了。

说到这里，由悲观锁涉及到的另外两个锁概念就出来了，它们就是共享锁与排它锁。共享锁和排它锁是悲观锁的不一样的实现，它俩都属于悲观锁的范畴。

 

共享锁

共享锁指的就是对于多个不一样的事务，对同一个资源共享同一个锁。至关于对于同一把门，它拥有多个钥匙同样。就像这样，你家有一个大门，大门的钥匙有好几把，你有一把，你女友有一把，大家均可能经过这把钥匙进入大家家，一下理解了哈，没错，这个就是所谓的共享锁。

刚刚说了，对于悲观锁，通常数据库已经实现了，共享锁也属于悲观锁的一种，那么共享锁在mysql中是经过什么命令来调用呢。经过查询资料，了解到经过在执行语句后面加上lock in share mode就表明对某些资源加上共享锁了。

好比，我这里经过mysql打开两个查询编辑器，在其中开启一个事务，并不执行commit语句
 

begin;
SELECT * from city where id = "1"  lock in share mode;

 

而后在另外一个查询窗口中，对id为1的数据进行更新

 

 

update  city set name="666" where id ="1";

此时，操做界面进入了卡顿状态，过几秒后，也提示错误信息

[SQL]update  city set name="666" where id ="1";
[Err] 1205 - Lock wait timeout exceeded; try restarting transaction

 

那么证实，对于id=1的记录加锁成功了，在上一条记录尚未commit以前，这条id=1的记录被锁住了，只有在上一个事务释放掉锁后才能进行操做，或用共享锁才能对此数据进行操做。

再实验一下：

 

 

update city set name="666" where id ="1" lock in share mode;

[Err] 1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'lock in share mode' at line 1

 

加上共享锁后，也提示错误信息了，经过查询资料才知道，对于update,insert,delete语句会自动加排它锁的缘由

 

因而，我又试了试SELECT * from city where id = "1" lock in share mode;

这下成功了。

排它锁

排它锁与共享锁相对应，就是指对于多个不一样的事务，对同一个资源只能有一把锁。

与共享锁类型，在须要执行的语句后面加上for update就能够了

 

行锁

行锁，由字面意思理解，就是给某一行加上锁，也就是一条记录加上锁。

好比以前演示的共享锁语句

SELECT * from city where id = "1"  lock in share mode; 

因为对于city表中,id字段为主键，就也至关于索引。执行加锁时，会将id这个索引为1的记录加上锁，那么这个锁就是行锁。

以上是转发他人；

下面我说一下laravel中的乐观锁 悲观锁

悲观锁 & 乐观锁

悲观锁（Pessimistic Lock），顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，因此每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁。传统的关系型数据库里边就用到了不少这种锁机制，好比行锁、表锁、读锁、写锁等，都是在作操做以前先上锁。

乐观锁（Optimistic Lock），顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，因此不会上锁，可是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可使用版本号等机制实现。乐观锁适用于多读的应用类型，这样能够提升吞吐量，像数据库若是提供相似于 write_condition 机制的其实都是提供的乐观锁。

下面咱们看下悲观锁和乐观锁在 Laravel 中的使用：

悲观锁使用

Laravel 查询构建器提供了一些方法帮助你在 select 语句中实现“悲观锁”。能够在查询中使用 sharedLock 方法从而在运行语句时带一把”共享锁“。共享锁能够避免被选择的行被修改直到事务提交：

DB::table('users')->where('votes', '>', 100)->sharedLock()->get();

上面这个查询等价于下面这条 SQL 语句：

select * from `users` where `votes` > '100' lock in share mode

此外你还可使用 lockForUpdate 方法。“for update”锁避免选择行被其它共享锁修改或删除：

DB::table('users')->where('votes', '>', 100)->lockForUpdate()->get();

上面这个查询等价于下面这条 SQL 语句：

select * from `users` where `votes` > '100' for update

for update 与 lock in share mode 都是用于确保被选中的记录值不能被其它事务更新（上锁），二者的区别在于 lock in share mode 不会阻塞其它事务读取被锁定行记录的值，而 for update 会阻塞其余锁定性读对锁定行的读取（非锁定性读仍然能够读取这些记录，lock in share mode 和 for update 都是锁定性读）。

这么说比较抽象，咱们举个计数器的例子：在一条语句中读取一个值，而后在另外一条语句中更新这个值。使用 lock in share mode 的话能够容许两个事务读取相同的初始化值，因此执行两个事务以后最终计数器的值+1；而若是使用 for update 的话，会锁定第二个事务对记录值的读取直到第一个事务执行完成，这样计数器的最终结果就是+2了。

乐观锁使用

乐观锁，大可能是基于数据版本 （ Version ）记录机制实现。何谓数据版本？即为数据增长一个版本标识，在基于数据库表的版本解决方案中，通常是经过为数据库表增长一个 “version” 字段来实现。

读取出数据时，将此版本号一同读出，以后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，若是提交的数据版本号大于数据库表当前版本号，则予以更新，不然认为是过时数据。

总结

两种锁各有优缺点，不可认为一种好于另外一种，像乐观锁适用于写比较少的状况下，即冲突真的不多发生的时候，这样能够省去了锁的开销，加大了系统的整个吞吐量。但若是常常产生冲突，上层应用会不断的进行重试，这样反却是下降了性能，因此这种状况下用悲观锁就比较合适。