大橙子网站建设,新征程启航
为企业提供网站建设、域名注册、服务器等服务
关于mysql中的乐观锁和悲观锁面试的时候被问到的概率还是比较大的。
成都创新互联服务项目包括官渡网站建设、官渡网站制作、官渡网页制作以及官渡网络营销策划等。多年来,我们专注于互联网行业,利用自身积累的技术优势、行业经验、深度合作伙伴关系等,向广大中小型企业、政府机构等提供互联网行业的解决方案,官渡网站推广取得了明显的社会效益与经济效益。目前,我们服务的客户以成都为中心已经辐射到官渡省份的部分城市,未来相信会继续扩大服务区域并继续获得客户的支持与信任!
mysql的悲观锁:
其实理解起来非常简单,当数据被外界修改持保守态度,包括自身系统当前的其他事务,以及来自外部系统的事务处理,因此,在整个数据处理过程中,将数据处于锁定状态。悲观锁的实现,往往依靠数据库提供的锁机制,但是也只有数据库层提供的锁机制才能真正保证数据访问的排他性,否则,即使在自身系统中实现了加锁机制,也无法保证外部系统不会修改数据。
来点实际的,当我们使用悲观锁的时候我们首先必须关闭mysql数据库的自动提交属性,因为MySQL默认使用autocommit模式,也就是说,当你执行一个更新操作后,MySQL会立刻将结果进行提交。
关闭命令为:set autocommit=0;
悲观锁可以使用select…for update实现,在执行的时候会锁定数据,虽然会锁定数据,但是不影响其他事务的普通查询使用。此处说普通查询就是平时我们用的:select * from table 语句。在我们使用悲观锁的时候事务中的语句例如:
//开始事务
begin;/begin work;/start transaction; (三选一)
//查询信息
select * from order where id=1 for update;
//修改信息
update order set name='names';
//提交事务
commit;/commit work;(二选一)
此处的查询语句for update关键字,在事务中只有SELECT ... FOR UPDATE 或LOCK IN SHARE MODE 同一条数据时会等待其它事务结束后才执行,一般的SELECT查询则不受影响。
执行事务时关键字select…for update会锁定数据,防止其他事务更改数据。但是锁定数据也是有规则的。
查询条件与锁定范围:
1、具体的主键值为查询条件
比如查询条件为主键ID=1等等,如果此条数据存在,则锁定当前行数据,如果不存在,则不锁定。
2、不具体的主键值为查询条件
比如查询条件为主键ID1等等,此时会锁定整张数据表。
3、查询条件中无主键
会锁定整张数据表。
4、如果查询条件中使用了索引为查询条件
明确指定索引并且查到,则锁定整条数据。如果找不到指定索引数据,则不加锁。
悲观锁的确保了数据的安全性,在数据被操作的时候锁定数据不被访问,但是这样会带来很大的性能问题。因此悲观锁在实际开发中使用是相对比较少的。
mysql的乐观锁:
相对悲观锁而言,乐观锁假设数据一般情况下不会造成冲突,所以在数据进行提交更新的时候,才会对数据的冲突与否进行检测,如果发现冲突,则让返回用户错误的信息,让用户决定如何去做。
一般来说,实现乐观锁的方法是在数据表中增加一个version字段,每当数据更新的时候这个字段执行加1操作。这样当数据更改的时候,另外一个事务访问此条数据进行更改的话就会操作失败,从而避免了并发操作错误。当然,还可以将version字段改为时间戳,不过原理都是一样的。
例如有表student,字段:
id,name,version
1 a 1
当事务一进行更新操作:update student set name='ygz' where id = #{id} and version = #{version};
此时操作完后数据会变为id = 1,name = ygz,version = 2,当另外一个事务二同样执行更新操作的时候,却发现version != 1,此时事务二就会操作失败,从而保证了数据的正确性。
悲观锁和乐观锁都是要根据具体业务来选择使用,本文仅作简单介绍。
你说的这个version是mysql底层的锁机制提供的,并不是java提供的。
使用数据版本(Version)记录机制实现,这是mysql乐观锁最常用的一种实现方式。所谓的数据版本就是给数据增加一个版本标识,一般是通过为数据库表增加一个数字类型的 “version” 字段来实现。当读取数据时,将version字段的值一同读出,数据每更新一次,对此version值加1。当我们提交更新的时候,判断数据库表对应记录的当前版本信息与第一次取出来的version值进行比对,如果数据库表当前版本号与第一次取出来的version值相等,则予以更新,否则认为是过期数据,版本号重新读取再做更新。
以上不是重点,重点是 对事务控制语句不熟悉。
SAVEPOINT identifier : 在事务中 创建保存点。一个事务中 允许有多个保存点。
RELEASE SAVEPOINT identifier : 删除保存点。当事务中 没有指定的 保存点,执行该语句 会抛异常。
ROLLBACK TO identifier : 把事务回滚到 保存点。
Say you have a table T with a column C with one row in it, say it has the value '1'. And consider you have a simple task like following:
That is a simple task that issue two reads from table T, with a delay of 1 minute between them.
If you follow the logic above you can quickly realize that SERIALIZABLE transactions, while they may make life easy for you, are always completely blocking every possible concurrent operation, since they require that nobody can modify, delete nor insert any row. The default transaction isolation level of the .Net System.Transactions scope is serializable, and this usually explains the abysmal performance that results.
在Repeatable Read隔离级别下,一个事务可能会遇到幻读(Phantom Read)的问题。
幻读是指,在一个事务中,第一次查询某条记录,发现没有,但是,当试图更新这条不存在的记录时,竟然能成功,并且,再次读取同一条记录,它就神奇地出现了。
我们仍然先准备好students表的数据:
然后,分别开启两个MySQL客户端连接,按顺序依次执行事务A和事务B:
事务B在第3步第一次读取id=99的记录时,读到的记录为空,说明不存在id=99的记录。随后,事务A在第4步插入了一条id=99的记录并提交。事务B在第6步再次读取id=99的记录时,读到的记录仍然为空,但是,事务B在第7步试图更新这条不存在的记录时,竟然成功了,并且,事务B在第8步再次读取id=99的记录时,记录出现了。
可见,幻读就是没有读到的记录,以为不存在,但其实是可以更新成功的,并且,更新成功后,再次读取,就出现了。
在冲突较少的情况下,使用乐观锁。乐观锁 因为没有 加锁 释放锁,也减少了 加锁 释放锁的开销。
冲突较多时,如果使用乐观锁 需要不停地尝试,所以 使用悲观锁。
如果乐观锁 进行尝试时 的花销较大,也是使用悲观锁。