解决并发问题,数据库常用的两把锁——悲观锁,乐观锁

一、概念:

乐观锁:适用于写少读多的情景,因为这种乐观锁相当于java的cas(比较并替换),所以多条数据同事过来的时候不用等待,可以立即进行返回

悲观锁:适用于写多读少的情景,这种情况也相当于java的synchronized,reentrantLock等,大量数据过来的时候,只有一条被写入,其他数据需要等待,智行完成后下一条数据继续。

二:实现方式:

乐观锁:采用版本号的方式。即当前版本号如果对应上了就可以写入数据,如果判断当前版本号不一致,那么就不会更新成功。

比如

  1. update table set column = value
  2. where version=${version} and otherKey = ${otherKey}

悲观锁实现的机制一般是在执行更新语句的时候采用for update方式,比如

  1. update table set column=‘value‘ for update

这种情况where条件呢一定要涉及到数据库对应的索引字段,这样才会是行级锁,否则会是表锁,这样执行速度会变慢。

实现乐观锁的方式有两种:

  1. 更新的时候将version字段传过来,然后更新的时候就可以进行version判断,如果version可以匹配上,那么就可以更新(方法:updateCatalogWithVersion)。
  2. 在实体类上的version字段上加入version,可以不用自己写SQL语句就可以它就可以自行的按照version匹配和更新,是不是很简单。 

实现悲观锁的时候也有两种方式:

  1. 自行写原生SQL,然后写上for update语句。(方法:findCatalogsForUpdate)
  2. 使用@Lock注解,并且设置值为LockModeType.PESSIMISTIC_WRITE即可代表行级锁。

链接(https://mp.weixin.qq.com/s/mGDGA-_dKehavAqsY7gauA)

原文地址:https://www.cnblogs.com/sunny-miss/p/10599224.html

时间: 2024-11-10 07:40:23

解决并发问题,数据库常用的两把锁——悲观锁,乐观锁的相关文章

Elasticsearch由浅入深(四)ES并发冲突、悲观锁与乐观锁、_version乐观锁并发

ES并发冲突 举个例子,比如是电商场景下,假设说,我们有个程序,工作的流程是这样子的: 读取商品信息(包含了商品库存) 用户下单购买 更新商品信息(主要是将库存减1) 我们比如咱们的程序就是多线程的,所以可能有多个线程并发的去执行上述的3步骤流程 有一个牙膏,库存100件,现在,同时有两个人都过来读取了牙育的数据,然后下单购买了这管牙膏,此时两个线程并发的服务于两个人,同时在进行商品库存数据的修改 总有一个线程是先到的,假设就是线程A ,此时线程A就会先将牙育的库存设置为99件,然后线程B再次将

web开发中的两把锁之数据库锁:(高并发--乐观锁、悲观锁)

这篇文章讲了 1.同步异步概念(消去很多疑惑),同步就是一件事一件事的做:sychronized就是保证线程一个一个的执行. 2.我们需要明白,锁机制有两个层面,一种是代码层次上的,如Java中的同步锁,典型的就是同步关键字synchronized ( 线    程级别的).另一个就是数据库层次上的,比较典型的就是悲观锁和乐观锁. 3.常见并发同步案例分析   附原文链接 http://www.cnblogs.com/xiohao/p/4385508.html 对于我们开发的网站,如果网站的访问

数据库锁解决并发问题

问题描述: 一个优惠券活动,用户可以领取优惠券,但是一个优惠券活动领取数量有限制,所以用户在领取的时候就需要先统计一下以领用的优惠券数量. 然后在生成这张优惠券领取记录.那么此时就会出现并发问题,当多个用户领取同一个优惠券活动的时候,他们统计的优惠券已领数量小于限定可领取数量,所以都可以执行生成 优惠券领取记录的操作,但是剩下的可领取数量可能小于这些用户数量. 如何来解决这个问题呢,首先我们会想到,在程序中使用synchronized关键字来锁住领取优惠券的方法,那么就可以实现,当一个人在领取优

乐观锁解决高并发

对于我们开发的网站,如果网站的访问量非常大的话,那么我们就需要考虑相关的并发访问问题了.而并发问题是绝大部分的程序员头疼的问题, 但话又说回来了,既然逃避不掉,那我们就坦然面对吧~今天就让我们一起来研究一下常见的并发和同步吧. 为了更好的理解并发和同步,我们需要先明白两个重要的概念:同步和异步    1.同步和异步的区别和联系          所谓同步,可以理解为在执行完一个函数或方法之后,一直等待系统返回值或消息,这时程序是出于阻塞的,只有接收到 返回的值或消息后才往下执行其它的命令. 异步

使用mysql乐观锁解决并发问题

案例说明: 银行两操作员同时操作同一账户.比如A.B操作员同时读取一余额为1000元的账户,A操作员为该账户增加100元,B操作员同时为该账户扣除50元,A先提交,B后提交.最后实际账户余额为1000-50=950元,但本该为1000+100-50=1050.这就是典型的并发问题. 乐观锁机制在一定程度上解决了这个问题.乐观锁,大多是基于数据版本(Version)记录机制实现.何谓数据版本?即为数据增加一个版本标识,在基于数据库表的版本解决方案中,一般是通过为数据库表增加一个 “version”

使用mysql乐观锁解决并发问题思路

本文摘自网络,仅供个人学习之用 案例说明: 银行两操作员同时操作同一账户.比如A.B操作员同时读取一余额为1000元的账户,A操作员为该账户增加100元,B操作员同时为该账户扣除50元,A先提交,B后提交.最后实际账户余额为1000-50=950元,但本该为1000+100-50=1050.这就是典型的并发问题. 乐观锁机制在一定程度上解决了这个问题.乐观锁,大多是基于数据版本(Version)记录机制实现.何谓数据版本?即为数据增加一个版本标识,在基于数据库表的版本解决方案中,一般是通过为数据

MySQL锁解决并发问题详解

文章分为以下几个要点 问题描述以及解决过程 MySQL锁机制 数据库加锁分析 下面讨论的都是基于MySQL的InnoDB. 0. 问题描述以及解决过程 因为涉及到公司利益问题,所以下面很多代码和数据库信息,进行了缩减和修改,望见谅. 业务场景是优惠券系统规则规定了一个优惠券活动最多可发行多少张优惠券和每个用户最多可领取优惠券数量. 下面列出两张表的结构. 活动表 CREATE TABLE `coupon_activity` ( `act_id` int(11) NOT NULL AUTO_INC

乐观锁与悲观锁——解决并发问题(转)

引言 为什么需要锁(并发控制)? 在多用户环境中,在同一时间可能会有多个用户更新相同的记录,这会产生冲突.这就是著名的并发性问题. 典型的冲突有: 丢失更新:一个事务的更新覆盖了其它事务的更新结果,就是所谓的更新丢失.例如:用户A把值从6改为2,用户B把值从2改为6,则用户A丢失了他的更新. 脏读:当一个事务读取其它完成一半事务的记录时,就会发生脏读取.例如:用户A,B看到的值都是6,用户B把值改为2,用户A读到的值仍为6. 为了解决这些并发带来的问题. 我们需要引入并发控制机制. 并发控制机制

乐观锁与悲观锁——解决并发问题

悲观锁(Pessimistic Lock), 顾名思义,就是很悲观,每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁,这样别人想拿这个数据就会block直到它拿到锁.传统的关系型数据库里边就用到了很多这种锁机制,比如行锁,表锁等,读锁,写锁等,都是在做操作之前先上锁. 乐观锁(Optimistic Lock), 顾名思义,就是很乐观,每次去拿数据的时候都认为别人不会修改,所以不会上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据,可以使用版本号等机制.乐观锁适用于