09.深入理解乐观锁与悲观锁

在数据库的锁机制中.数据库管理系统(DBMS)中的并发控制的任务是确保在多个事务同时存取数据库中同一数据,不破坏事务的隔离性和统一性以及数据库的统一性.

乐观并发控制(乐观锁)和悲观并发控制(悲观锁)是并发控制主要采用的技术手段.
其实不仅仅是关系型数据库系统中有乐观锁和悲观锁的概念,像memcache、hibernate、tair等都有类似的概念。

针对于不同的业务场景,应该选用不同的并发控制方式。
所以,不要把乐观并发控制和悲观并发控制狭义的理解为DBMS中的概念,更不要把他们和数据中提供的锁机制(行锁、表锁、排他锁、共享锁)混为一谈。
其实,在DBMS中,悲观锁正是利用数据库本身提供的锁机制来实现的。

  • 悲观锁:指的是对数据被外界(包括本系统当前的其他事务,以及来自外部系统的事务处理)修改持保守态度(悲观),因此,在整个数据处理过程中,将数据处于锁定状态。

如果一个事务执行的操作对某行数据应用了锁,那只有当这个事务把锁释放,其他事务才能够执行与该锁冲突的操作。
悲观并发控制主要用于数据争用激烈的环境,以及发生并发冲突时使用锁保护数据的成本要低于回滚事务的成本的环境中。

数据库中,悲观锁的流程如下:

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

MySql InnoDB使用悲观锁

要使用悲观锁,我们必须关闭mysql数据库的自动提交属性,因为mysql默认使用autocommit模式,也就是说,当你执行一个更新操作后,mysql会立即将结果进行提交.
也就是set autocommit=0;

//0.开始事务
begin;/begin work;/start transaction;(三选1即可)
//1.查询出商品信息
select status from t_goods where id =1 for update;
//2.根据商品信息生成订单
insert into t_orders(id,goods_id) values(null,1);
//3.修改商品status为2
update t_goods set status =2;
//4.提交事务
commit;/commit work;

查询语句中,使用了select ...for update的方式,
这样就通过开启排他锁的方式实现了悲观锁.
此时在t_goods表中,id为1的那条数据就被我们锁定了,
其他的事务必须等本次事务提交之后才能提交.
这样我们就能保证当前的数据不会被其他事务修改.

使用select ...for update 会把数据锁住,
Mysql InnoDB默认行级锁.行级锁都是基于索引的.

如果一条SQL语句用不到索引是不会使用行级锁的,
会使用标级锁把整张表锁住.

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

乐观锁

乐观并发控制(乐观锁,OCC)是一种并发控制.
它假设多用户并发的事务在处理时不会彼此互相影响,各事务能够在不产生锁的情况下处理各自影响的那部分数据.
在提交数据更新之前,每个事务会先检查在该事务读取数据后,在没有其他事务又修改了该数据.
如果其他事务有更新的话,正在提交的事务会进行回滚。乐观事务控制最早是由孔祥重(H.T.Kung)教授提出。

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

相对于悲观锁,在对数据库进行处理的时候,乐观锁并不会使用数据库提供的锁机制。一般的实现乐观锁的方式就是记录数据版本。
实现数据版本有两种方式,第一种是使用版本号,第二种是使用时间戳。

使用版本号实现乐观锁

使用版本号时,可以在数据初始化时指定一个版本号,
每次对数据的更新操作都对版本号执行+1操作.
并判断当前版本号是不是该数据的最新的版本号.

1.查询商品信息
select (status,status,status) 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};

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

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 200,527评论 5 470
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 84,314评论 2 377
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 147,535评论 0 332
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,006评论 1 272
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 62,961评论 5 360
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,220评论 1 277
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,664评论 3 392
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,351评论 0 254
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,481评论 1 294
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,397评论 2 317
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,443评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,123评论 3 315
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,713评论 3 303
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,801评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,010评论 1 255
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,494评论 2 346
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,075评论 2 341

推荐阅读更多精彩内容