澳门新葡萄京娱乐网站-澳门新葡萄京888官网-所有平台

热门关键词: 澳门新葡萄京娱乐网站,澳门新葡萄京888官网

浅谈数据库乐观锁和悲观锁,数据库事务与锁详

作者: MySQL数据库  发布:2019-12-22

privot多对多关系的中间表。PT5框架会自动把privot带上。

在单实例JVM中,常见的处理并发问题的方法有很多,比如synchronized关键字进行访问控制、volatile关键字、ReentrantLock等常用方法。但是在分布式环境中,上述方法却不能在跨jvm场景中用于处理并发问题,当业务场景需要对分布式环境中的并发问题进行处理时,需要使用其他方式来实现,如数据库锁机制、缓存数据库如redis以及zookeeper分布式锁等。

什么是事务(Transaction)?

是指作为单个逻辑工作单元执行的一系列操作,要么完全地执行,要么完全地不执行。 事务处理可以确保除非事务性单元内的所有操作都成功完成,否则不会永久更新面向数据的资源。通过将一组相关操作组合为一个要么全部成功要么全部失败的单元,可以简化错误恢复并使应用程序更加可靠。一个逻辑工作单元要成为事务,必须满足所谓的ACID(原子性、一致性、隔离性和持久性)属性。事务是数据库运行中的一个逻辑工作单位,由DBMS中的事务管理子系统负责事务的处理。

举个例子加深一下理解:同一个银行转账,A转1000块钱给B,这里存在两个操作,一个是A账户扣款1000元,两一个操作是B账户增加1000元,两者就构成了转账这个事务。

  • 两个操作都成功,A账户扣款1000元,B账户增加1000元,事务成功
  • 两个操作都失败,A账户和B账户金额都没变,事务失败

最后思考一下,怎么样会出现A账户扣款1000元,B账户金额不变?如果你是把两个操作放在一个事务里面,并且是数据库提供的内在事务支持,那就不会有问题,但是开发人员把两个操作放在两个事务里面,而第二个事务失败就会出现中间状态。现实中自己实现的分布式事务处理不当也会出现中间状态,这并不是事务的错,事务本身就是规定不会出现中间状态,是事务实现者做出来的方案有问题。

我们需要隐藏,因为我们不需要privot,而且pritvot也不在我们模型本身,他是中间数据

本文主要介绍数据库中常用的乐观锁和悲观锁的实现以及优缺点。

事务的4个特性

  • 原子性(Atomic):事务必须是原子工作单元;对于其数据修改,要么全都执行,要么全都不执行。通常,与某个事务关联的操作具有共同的目标,并且是相互依赖的。如果系统只执行这些操作的一个子集,则可能会破坏事务的总体目标。原子性消除了系统处理操作子集的可能性。

  • 一致性(Consistency):事务的一致性指的是在一个事务执行之前和执行之后数据库都必须处于一致性状态。这种特性称为事务的一致性。假如数据库的状态满足所有的完整性约束,就说该数据库是一致的。

  • 隔离性(Isolation):由并发事务所作的修改必须与任何其它并发事务所作的修改隔离。事务查看数据时数据所处的状态,到底是另一个事务执行之前的状态还是中间某个状态,相互之间存在什么影响,是可以通过隔离级别的设置来控制的。

  • 持久性(Durability):事务结束后,事务处理的结果必须能够得到固化,即写入数据库文件中即使机器宕机数据也不会丢失,它对于系统的影响是永久性的。

另外冗余字段,我们有一个表是记录图片的,另一个表是记录商品的。

数据库乐观锁:

事务并发控制

我们从另外一个方向来说说,如果不对事务进行并发控制,我们看看数据库并发操作是会有那些异常情形,有些使我们可以接受的,有些是不能接受的,注意这里的异常就是特定语境下的,并不一定就是错误什么的。假设有一个order表,有个字段叫count,作为计数用,当前值为100

  • 第一类丢失更新(Update Lost):此种更新丢失是因为回滚的原因,所以也叫回滚丢失。此时两个事务同时更新count,两个事务都读取到100,事务一更新成功并提交,count=100+1=101,事务二出于某种原因更新失败了,然后回滚,事务二就把count还原为它一开始读到的100,此时事务一的更新就这样丢失了。

  • 脏读(Dirty Read):此种异常时因为一个事务读取了另一个事务修改了但是未提交的数据。举个例子,事务一更新了count=101,但是没有提交,事务二此时读取count,值为101而不是100,然后事务一出于某种原因回滚了,然后第二个事务读取的这个值就是噩梦的开始。

  • 不可重复读(Not Repeatable Read):此种异常是一个事务对同一行数据执行了两次或更多次查询,但是却得到了不同的结果,也就是在一个事务里面你不能重复(即多次)读取一行数据,如果你这么做了,不能保证每次读取的结果是一样的,有可能一样有可能不一样。造成这个结果是在两次查询之间有别的事务对该行数据做了更新操作。举个例子,事务一先查询了count,值为100,此时事务二更新了count=101,事务一再次读取count,值就会变成101,两次读取结果不一样。

  • 第二类丢失更新(Second Update Lost):此种更新丢失是因为更新被其他事务给覆盖了,也可以叫覆盖丢失。举个例子,两个事务同时更新count,都读取100这个初始值,事务一先更新成功并提交,count=100+1=101,事务二后更新成功并提交,count=100+1=101,由于事务二count还是从100开始增加,事务一的更新就这样丢失了。

  • 幻读(Phantom Read):幻读和不可重复读有点像,只是针对的不是数据的值而是数据的数量。此种异常是一个事务在两次查询的过程中数据的数量不同,让人以为发生幻觉,幻读大概就是这么得来的吧。举个例子,事务一查询order表有多少条记录,事务二新增了一条记录,然后事务一查了一下order表有多少记录,发现和第一次不一样,这就是幻读。

我们可以在图片你放商品图片里的url

定义:顾名思义,系统认为数据的更新在大多数情况下是不会产生冲突的,只在数据库更新操作提交的时候才对数据作冲突检测。如果检测的结果出现了与预期数据不一致的情况,则返回失败信息。

数据库事务隔离级别

看到上面提到的几种问题,你可能会想,我擦,这么多坑怎么办啊。其实上面几种情况并不是一定都要避免的,具体看你的业务要求,包括你数据库的负载都会影响你的决定。不知道大家发现没有,上面各种异常情况都是多个事务之间相互影响造成的,这说明两个事务之间需要某种方式将他们从某种程度上分开,降低直至避免相互影响。这时候数据库事务隔离级别就粉墨登场了,而数据库的隔离级别实现一般是通过数据库锁实现的。

  • 读未提交(Read Uncommitted):该隔离级别指即使一个事务的更新语句没有提交,但是别的事务可以读到这个改变,几种异常情况都可能出现。极易出错,没有安全性可言,基本不会使用。

  • 读已提交(Read Committed):该隔离级别指一个事务只能看到其他事务的已经提交的更新,看不到未提交的更新,消除了脏读和第一类丢失更新,这是大多数数据库的默认隔离级别,如Oracle,Sqlserver。

  • 可重复读(Repeatable Read):该隔离级别指一个事务中进行两次或多次同样的对于数据内容的查询,得到的结果是一样的,但不保证对于数据条数的查询是一样的,只要存在读改行数据就禁止写,消除了不可重复读和第二类更新丢失,这是Mysql数据库的默认隔离级别。

  • 串行化(Serializable):意思是说这个事务执行的时候不允许别的事务并发执行.完全串行化的读,只要存在读就禁止写,但可以同时读,消除了幻读。这是事务隔离的最高级别,虽然最安全最省心,但是效率太低,一般不会用。

同时商品里放图片id和图片URL

实现方式:

下面是各种隔离级别对各异常的控制能力:

级别异常 第一类更新丢失 脏读 不可重复读 第二类丢失更新 幻读
读未提交 Y Y Y Y Y
读已提交 N N Y Y Y
可重复读 N N N N Y
串行化 N N N N N

这两个字段是重复的,这就是数据冗余,我们设计数据库是不要出现冗余信息,为啥我们用冗余呢。

1. 借助数据库表增加一个版本号的字段version,每次更新一行记录,都使得该行版本号加一,开始更新之前先获取version的值,更新提交的时候带上之前获取的version值与当前version值作比较,如果不相等则说明version值发生了变化则检测到了并发冲突,本次操作执行失败,如果相等则操作执行成功。

数据库锁分类

一般可以分为两类,一个是悲观锁,一个是乐观锁,悲观锁一般就是我们通常说的数据库锁机制,乐观锁一般是指用户自己实现的一种锁机制,比如hibernate实现的乐观锁甚至编程语言也有乐观锁的思想的应用。

悲观锁:顾名思义,就是很悲观,它对于数据被外界修改持保守态度,认为数据随时会修改,所以整个数据处理中需要将数据加锁。悲观锁一般都是依靠关系数据库提供的锁机制,事实上关系数据库中的行锁,表锁不论是读写锁都是悲观锁。

主要是为了出于对查询性能的考虑。

例如:update table set columnA = 1,version=version+1 where id=#{id} and version = #{oldVersion}

悲观锁按照使用性质划分:

  • 共享锁(Share locks简记为S锁):也称读锁,事务A对对象T加s锁,其他事务也只能对T加S,多个事务可以同时读,但不能有写操作,直到A释放S锁。

  • 排它锁(Exclusivelocks简记为X锁):也称写锁,事务A对对象T加X锁以后,其他事务不能对T加任何锁,只有事务A可以读写对象T直到A释放X锁。

  • 更新锁(简记为U锁):用来预定要对此对象施加X锁,它允许其他事务读,但不允许再施加U锁或X锁;当被读取的对象将要被更新时,则升级为X锁,主要是用来防止死锁的。因为使用共享锁时,修改数据的操作分为两步,首先获得一个共享锁,读取数据,然后将共享锁升级为排它锁,然后再执行修改操作。这样如果同时有两个或多个事务同时对一个对象申请了共享锁,在修改数据的时候,这些事务都要将共享锁升级为排它锁。这些事务都不会释放共享锁而是一直等待对方释放,这样就造成了死锁。如果一个数据在修改前直接申请更新锁,在数据修改的时候再升级为排它锁,就可以避免死锁。

我们在这里做了数据冗余,我们就可以减少对图片表的查询,加速查询速度!

2. 借助行更新时间时间戳,检测方法则与方式1相似,即更新操作执行前先获取记录当前的更新时间,在提交更新时,检测当前更新时间是否与更新开始时获取的更新时间时间戳相等。

悲观锁按照作用范围划分:

  • 行锁:锁的作用范围是行级别,数据库能够确定那些行需要锁的情况下使用行锁,如果不知道会影响哪些行的时候就会使用表锁。举个例子,一个用户表user,有主键id和用户生日birthday当你使用update ... where id=?这样的语句数据库明确知道会影响哪一行,它就会使用行锁,当你使用update ... where birthday=?这样的的语句的时候因为事先不知道会影响哪些行就可能会使用表锁。
  • 表锁:锁的作用范围是整张表。

乐观锁:顾名思义,就是很乐观,每次自己操作数据的时候认为没有人回来修改它,所以不去加锁,但是在更新的时候会去判断在此期间数据有没有被修改,需要用户自己去实现。既然都有数据库提供的悲观锁可以方便使用为什么要使用乐观锁呢?对于读操作远多于写操作的时候,大多数都是读取,这时候一个更新操作加锁会阻塞所有读取,降低了吞吐量。最后还要释放锁,锁是需要一些开销的,我们只要想办法解决极少量的更新操作的同步问题。换句话说,如果是读写比例差距不是非常大或者你的系统没有响应不及时,吞吐量瓶颈问题,那就不要去使用乐观锁,它增加了复杂度,也带来了额外的风险。

不过推荐大家滥用数据冗余,因为数据冗余对于数据完整性,和一致性维护很困难。有两个地方记录相同的信息,但我们去写入数据的时候,就需要写入到两个地方。最大的问题在于删除和跟新。更新的时候一个地方的IMG改变了,要更改两个。否则就会产生数据不一致。不过数据冗余用的还是挺多的。

3. 前面2种方式都是提交的时候检测版本有没有改变,只要有变化都会失败,而有一类场景当字段只需要满足一个区间范围并不关心是否有数据更新冲突,且本身进行更新并且作为判断条件时,可不借助其他字段,对字段本身作判断即可。例如一个较常见的场景:库存的扣减,只要扣减后的值大于等于零即可。例如:update product set rest = rest– #{deduct} where name = ‘abc’ and rest >= #{deduct

乐观锁实现方式:

  • 版本号(记为version):就是给数据增加一个版本标识,在数据库上就是表中增加一个version字段,每次更新把这个字段加1,读取数据的时候把version读出来,更新的时候比较version,如果还是开始读取的version就可以更新了,如果现在的version比老的version大,说明有其他事务更新了该数据,并增加了版本号,这时候得到一个无法更新的通知,用户自行根据这个通知来决定怎么处理,比如重新开始一遍。这里的关键是判断version和更新两个动作需要作为一个原子单元执行,否则在你判断可以更新以后正式更新之前有别的事务修改了version,这个时候你再去更新就可能会覆盖前一个事务做的更新,造成第二类丢失更新,所以你可以使用update ... where ... and version="old version"这样的语句,根据返回结果是0还是非0来得到通知,如果是0说明更新没有成功,因为version被改了,如果返回非0说明更新成功。
  • 时间戳(timestamp):和版本号基本一样,只是通过时间戳来判断而已,注意时间戳要使用数据库服务器的时间戳不能是业务系统的时间。
  • 待更新字段:和版本号方式相似,只是不增加额外字段,直接使用有效数据字段做版本控制信息,因为有时候我们可能无法改变旧系统的数据库表结构。假设有个待更新字段叫count,先去读取这个count,更新的时候去比较数据库中count的值是不是我期望的值(即开始读的值),如果是就把我修改的count的值更新到该字段,否则更新失败。java的基本类型的原子类型对象如AtomicInteger就是这种思想。
  • 所有字段:和待更新字段类似,只是使用所有字段做版本控制信息,只有所有字段都没变化才会执行更新。

在WEB开发中,除了掌握一些必要的数据库优化技巧外,在合适的时候使用冗余字段也可以做到事半功倍的效果。比如下面这样一个例子,有这么几个表,是这么设计的。

优点与缺点分析,优点比较明显,由于在检测数据冲突时并不依赖数据库本身的锁机制,不会影响请求的性能,当产生并发且并发量较小的时候只有少部分请求会失败。缺点则是,一需要对表的设计增加额外的字段,增加了数据库的冗余,另外,当应用并发量高的时候,version值在频繁变化,则会导致大量请求失败,影响系统的可用性。我们通过上述sql语句还可以看到,数据库锁都是作用于同一行数据记录上,这就导致一个明显的缺点,在一些特殊场景,如大促、秒杀等活动开展的时候,大量的请求同时请求同一条记录的行锁,会对数据库产生很大的写压力。所以综合数据库乐观锁的优缺点,乐观锁比较适合并发量不高,并且写操作不频繁的场景。

乐观锁几种方式的区别:

新系统设计可以使用version方式和timestamp方式,需要增加字段,应用范围是整条数据,不论那个字段修改都会更新version,也就是说两个事务更新同一条记录的两个不相关字段也是互斥的,不能同步进行。旧系统不能修改数据库表结构的时候使用数据字段作为版本控制信息,不需要新增字段,待更新字段方式只要其他事务修改的字段和当前事务修改的字段没有重叠就可以同步进行,并发性更高。

用户表[user]:id,userName 项目表[project]:id,projectName, user_id 版本表[version]:id,versionName,project_id 分类表[category]:id,categoryName,version_id 内容表[content]:id,text,category_id

数据库悲观锁:

mysql事务隔离级别实战

实践是检验真理的唯一标准,掌握上面的理论之后,我们在数据库上实战一番家里更好地掌握也加深理解,同时有助于解决实际问题。不同数据库很多实现可能不同,这里以mysql为例讲解各种隔离级别下的情况,测试表为user(id,name,gender,passwd,email)。

差不多就是这样了。看着很不错,没有字段冗余。也符合数据库设计的三大范式。

定义:根据命名即对数据进行操作更新时,对操作持悲观保守的态度,认为产生数据冲突的可能性很大,需要先对请求的数据加锁再进行相关的操作。

隔离级别:read-uncommitted

脏读测试流程:

  1. A设置隔离级别为read-uncommitted(注意这里未声明都是session级别,而非全局的),开启事务,查询id=1的记录
  2. B设置隔离级别为read-uncommitted,开启事务,修改id=1的记录,但不提交
  3. A再次查询id=1的记录,和第一次查询的比较一下
  4. B事务回滚,A事务回滚。

A:

这里写图片描述

B:

这里写图片描述

结论:A读到了B没有提交的内容,隔离级别为read-uncommitted的时候出现脏读。

第一类更新丢失测试流程:

  1. A设置隔离级别为read-uncommitted,开启事务,查询id=1的记录
  2. B设置隔离级别为read-uncommitted,开启事务,查询id=1的记录
  3. A修改id=1的记录
  4. B修改id=1的记录
  5. A提交
  6. B回滚
  7. A在查询一次id=1的记录,看看自己的修改是否成功

结论:结果不如我所想的,A的更新成功了,为什么呢?A执行update语句的时候对该条记录加锁了,B这时候根本无法修改直至超时,也就是至少在mysql中在read-uncommitted隔离级别下验证第一类丢失更新,据了解有的数据库好像可以设置不加锁,如果能够不加锁的话则可以实现,也贴一下图吧。

A:

澳门新葡萄京888官网 1

输入图片说明

B:

澳门新葡萄京888官网 2

输入图片说明

不可重复读测试流程(省略):

结论:流程和测试脏读一样,其实在第一次测试脏读的时候就可以发现会出现不可重复读,A两次读取id=1的数据内容不同。

第二类丢失更新流程:

  1. A开启事务,查询order_id=1的记录
  2. B开启事务,查询order_id=1的记录
  3. A把查出来的count加1后更新
  4. B把查出来的count加1更新
  5. A提交,B也提交

A:

这里写图片描述

B:

这里写图片描述

结论:A的更新丢失,我们希望的结果是3,而实际结果是2,跟java的多线程很像对不对,read-uncommitted隔离模式下会出现第二类丢失更新。

幻读测试流程:

  1. A开启事务,查询user表所有数据
  2. B开启事务,新增一条记录
  3. A再次查询user表所有记录,和第一次作比对
  4. A回滚,B回滚

A:

这里写图片描述

B:

这里写图片描述

结论:A两次查询全表数据结果不同,read-uncommitted隔离模式下会出现幻读。

注:因为后面对这几种异常情况的测试流程基本和上面一样,个别有些差别读者自己注意,另外注意更改隔离级别即可,就能看到对应结果,后面的我只给出进一步能解决的异常测试截图,结论可以参照前面的对照表。

那我们先提个问题,命名为问题X吧。

实现方式:通过数据库锁机制实现,即对查询语句添加for update关键字。

隔离级别:read-committed

问题X:如果要查询某个版本下的内容列表,sql应该是这么写的:

如下sql语句 select * from table where id = 1 for update 当一个请求A开启事务并执行此sql同时未提交事务时,另一个线程B发起请求,此时B将阻塞在加了锁的查询语句上,直到A请求的事务提交或者回滚,B才会继续执行,保证了访问的隔离性。

脏读测试截图

A:

这里写图片描述

B:

这里写图片描述

结论:A没有读到B没有提交的内容,隔离级别为read-committed的时候不会出现脏读。

select c.* from content c, category t where c.category_id=t.id and t.version_id=?

悲观锁优缺点分析,优点是每一次行数据的访问都是独占的,只有当正在访问该行数据的请求事务提交以后,其他请求才能依次访问该数据,否则将阻塞等待锁的获取。悲观锁可以严格保证数据访问的安全,但是缺点也明显,即每次请求都会额外产生加锁的开销且未获取到锁的请求将会阻塞等待锁的获取,在高并发环境下,容易造成大量请求阻塞,影响系统可用性。另外,悲观锁使用不当还可能产生死锁的情况。

隔离级别:repeatable-read

好像也没什么问题。要怎么优化这个查询呢?这个问题我们最后再来说。讲回上面的表设计,如果有这样一个问题。举个例子,我要查询内容A是否属于用户U,那我应该怎么做?

我们来看如下情况,以商品表、用户商品列表为例:

不可重复读测试截图

A:

这里写图片描述

B:

这里写图片描述

结论:A两次读取id=1的数据内容相同,repeatable-read隔离模式下不会出现不可重复读。

查询内容A所属的分类B 查询分类B所属的版本C 查询版本C所属的项目D 查询项目D是否属于用户U,从而得出内容A是否属于用户U

系统出现了2个业务操作,操作A先查询商品表并加锁,根据查询的结果作更新用户商品列表状态字段的操作,sql为 select * from product where id = 10 for update;update user_product set status = 2  where user_id = 10001;。业务操作B先查询用户商品表并加锁,根据查询结果更新商品表剩余数量的操作,sql为select * from user_product where user_id = 10001 for update;update product set rest = rest - 1 where id = 10。

隔离级别:Serializable

这样的做法简直恶劣至极不是吗。此时你应该已深刻意识到这种表设计弱爆之处。那怎么做呢?

我们看一下产生死锁的过程:A业务操作开启事务,获取product表id=10的行锁,B业务操作接着开启事务并获取user_product表user_澳门新葡萄京888官网,id为10001记录的行锁,A继续执行更新操作,需要等待获取user_product表user_id为10001的行锁进入阻塞状态如下图1所示,B继续执行更新操作需要等待获取product表id=10的行锁。此时我们可以发现数据库的状态为A等待的锁被B占住,而B等待的锁被A所占住,双方事务都未提交都在等待对方释放锁,进入一个死循环状态。

幻读测试截图

A:

这里写图片描述

B:

这里写图片描述

结论:因为A事务未提交之前,B事务插入操作无法获得锁而超时,Serializable隔离模式下不会出现幻读。

冗余字段!没错,我们需要在表里添加冗余字段。如果在上述表都添加一个user_id字段,会怎么样呢?

如图2所示,数据库(mysql5.7)检测到产生了死锁,自动回滚了B操作的事务,释放了锁。虽然常见数据库如oracle或者mysql都有死锁检测机制,出现死锁数据库会自动回滚一个事务,但是也会造成系统的可用性和稳定性受到影响,我们应该避免在实际应用场景中出现死锁的情况,如上例所示,可以考虑把一个操作改为乐观锁实现或者改变锁的获取顺序使得2个操作都是先获取同一个锁再获取另外一个锁,以此避免死锁的发生。综合数据库悲观锁的特点,在

首先,可以确定,每个表的user_id字段的值都不会发生改变。所以,这个字段的值从一开始设定之后,就不用再修改了。

澳门新葡萄京888官网 3

然后,我们再回到上述的问题:查询内容A是否属于用户U。现在的做法是这样的:

图1  A操作执行其update操作时等待锁的获取

查询内容A的user_id是否为用户U的id

澳门新葡萄京888官网 4

就一步!好简单粗暴是吧!很爽快是吧!

图2  B操作执行update时,数据库检测到死锁则回滚

只需添加user_id这个冗余字段,就很大程度地方便了编码量,而且数据库的查询效率也提升N倍。还有,这个字段只需要维护一次!

并发量较小、又需要独占读取结果并依赖读取的结果进行判断的业务场景比较适合使用悲观锁。

现在知道冗余字段的威力了吧,回到问题X。怎么优化那个业务逻辑呢?

澳门新葡萄京888官网 5

正确的做法应该是:在content表中,添加多一个version_id字段,可以肯定,这个字段跟user_id字段类似,只需要维护一次。

本文作者:彭逆(点融黑帮),任职于点融工程部promotion团队高级软件工程师,对足球、电影、旅游、桌游非常有兴趣。

然后问题X的sql改为:

select c.* from content c where c.version_id=?

以上说明,有时候,适当的数据库冗余是个不错的选择。

总结

以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作具有一定的参考学习价值,谢谢大家对脚本之家的支持。如果你想了解更多相关内容请查看下面相关链接

本文由澳门新葡萄京娱乐网站发布于MySQL数据库,转载请注明出处:浅谈数据库乐观锁和悲观锁,数据库事务与锁详

关键词: