咱们知道,mysql的innodb采用的是行锁,并且采用了多版本并发控制来提升读操做的性能。
什么是多版本并发控制呢 ?其实就是在每一行记录的后面增长两个隐藏列,记录建立版本号和删除版本号,
而每个事务在启动的时候,都有一个惟一的递增的版本号。
一、在插入操做时 : 记录的建立版本号就是事务版本号。
好比我插入一条记录, 事务id 假设是1 ,那么记录以下:也就是说,建立版本号就是事务版本号。
id | name | create version | delete version |
1 | test | 1 |
二、在更新操做的时候,采用的是先标记旧的那行记录为已删除,而且删除版本号是事务版本号,而后插入一行新的记录的方式。
好比,针对上面那行记录,事务Id为2 要把name字段更新
update table set name= 'new_value' where id=1;
id | name | create version | delete version |
1 | test | 1 | 2 |
1 | new_value | 2 |
三、删除操做的时候,就把事务版本号做为删除版本号。好比
delete from table where id=1;
id | name | create version | delete version |
1 | new_value | 2 | 3 |
四、查询操做:
从上面的描述能够看到,在查询时要符合如下两个条件的记录才能被事务查询出来:
1)InnoDB只查找版本早于当前事务版本的数据行(也就是,行的系统版本号小于或等于事务的系统版本号),这样能够确保事务读取的行,只么是在事务开始前已经存在的,要么是事务自身插入或者修改过的。
2)行的删除版本要么未定义,要么大于当前事务版本号。这能够确保事务读取到的行,在事务开始以前未被删除。
这样就保证了各个事务互不影响。从这里也能够体会到一种提升系统性能的思路,就是:
经过版本号来减小锁的争用。
另外,只有read-committed和 repeatable-read 两种事务隔离级别才能使用mVcc
read-uncommited因为是读到未提交的,因此不存在版本的问题
而serializable 则会对全部读取的行加锁。
应用场景:
悲观锁:Synchroinzed 和Reentrant 都是悲观锁,传统的关系型数据库里边就用到了不少这种锁机制,好比行锁,表锁等,读锁,写锁等,都是在作操做以前先上锁。
乐观锁:数据库的多版本并发控制,MVCC,就是典型的乐观锁。
乐观锁和悲观锁的机制:
1. 乐观锁是一种思想,具体实现是,表中有一个版本字段,第一次读的时候,获取到这个字段。处理完业务逻辑开始更新的时候,须要再次查看该字段的值是否和第一次的同样。若是同样更新,反之拒绝。之因此叫乐观,由于这个模式没有从数据库加锁。
2. 悲观锁是读取的时候为后面的更新加锁,以后再来的读操做都会等待。这种是数据库锁
乐观锁优势程序实现,不会存在死锁等问题。它解决不了脏读的问题,他的适用场景也相对乐观。阻止不了除了程序以外的数据库操做。
悲观锁是数据库实现,他阻止一切数据库操做。
再来讲更新数据丢失,全部的读锁都是为了保持数据一致性。乐观锁若是有人在你以前更新了,你的更新应当是被拒绝的,可让用户重新操做。悲观锁则会等待前一个更新完成。这也是区别。具体业务具体分析乐观锁
乐观锁(Optimistic Lock), 顾名思义,就是很乐观,每次去拿数据的时候都认为别人不会修改,因此不会上锁,可是在更新的时候会判断一下在此期间别人有没有去更新这个数据,可使用版本号等机制。乐观锁适用于多读的应用类型,这样能够提升吞吐量,像数据库若是提供相似于write_condition机制的其实都是提供的乐观锁。
CAS即是乐观锁技术,当多个线程尝试使用CAS同时更新同一个变量时,只有其中一个线程能更新变量的值,而其它线程都失败,失败的线程并不会被挂起,而是被告知此次竞争中失败,并能够再次尝试。
CAS有3个操做数,内存值V,旧的预期值A,要修改的新值B。当且仅当预期值A和内存值V相同时,将内存值V修改成B,不然什么都不作。
悲观锁
悲观锁(Pessimistic Lock), 顾名思义,就是很悲观,每次去拿数据的时候都认为别人会修改,因此每次在拿数据的时候都会上锁,这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了不少这种锁机制,好比行锁,表锁等,读锁,写锁等,都是在作操做以前先上锁。
好比说synchronized就是一种独占锁,他假设最坏的状况,而且只有在确保其它线程不会形成干扰的状况下执行,会致使其它全部须要锁的线程挂起,等待持有锁的线程释放锁。
缺点:
因为在进程挂起和恢复执行过程当中存在着很大的开销。当一个线程正在等待锁时,它不能作任何事。举个栗子,若是一个线程须要某个资源,可是这个资源的占用时间很短,当线程第一次抢占这个资源时,可能这个资源被占用,若是此时挂起这个线程,可能马上就发现资源可用,而后又须要花费很长的时间从新抢占锁,时间代价就会很是的高。
悲观锁(Pessimistic Lock), 顾名思义,就是很悲观,每次去拿数据的时候都认为别人会修改,因此每次在拿数据的时候都会上锁,这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了不少这种锁机制,好比行锁,表锁等,读锁,写锁等,都是在作操做以前先上锁。
乐观锁(Optimistic Lock), 顾名思义,就是很乐观,每次去拿数据的时候都认为别人不会修改,因此不会上锁,可是在更新的时候会判断一下在此期间别人有没有去更新这个数据,可使用版本号等机制。乐观锁适用于多读的应用类型,这样能够提升吞吐量,像数据库若是提供相似于write_condition机制的其实都是提供的乐观锁。
典型的冲突有:
-
丢失更新:一个事务的更新覆盖了其它事务的更新结果,就是所谓的更新丢失。例如:用户A把值从6改成2,用户B把值从2改成6,则用户A丢失了他的更新。
-
脏读:当一个事务读取其它完成一半事务的记录时,就会发生脏读取。例如:用户A,B看到的值都是6,用户B把值改成2,用户A读到的值仍为6。
为了解决这些并发带来的问题。 咱们须要引入并发控制机制。
并发控制机制
悲观锁:假定会发生并发冲突,屏蔽一切可能违反数据完整性的操做。[1]
乐观锁:假设不会发生并发冲突,只在提交操做时检查是否违反数据完整性。[1] 乐观锁不能解决脏读的问题。
乐观锁介绍:
乐观锁( Optimistic Locking ) 相对悲观锁而言,乐观锁假设认为数据通常状况下不会形成冲突,因此在数据进行提交更新的时候,才会正式对数据的冲突与否进行检测,若是发现冲突了,则让返回用户错误的信息,让用户决定如何去作。那么咱们如何实现乐观锁呢,通常来讲有如下2种方式:
1.使用数据版本(Version)记录机制实现,这是乐观锁最经常使用的一种实现方式。何谓数据版本?即为数据增长一个版本标识,通常是经过为数据库表增长一个数字类型的 “version” 字段来实现。当读取数据时,将version字段的值一同读出,数据每更新一次,对此version值加一。当咱们提交更新的时候,判断数据库表对应记录的当前版本信息与第一次取出来的version值进行比对,若是数据库表当前版本号与第一次取出来的version值相等,则予以更新,不然认为是过时数据。用下面的一张图来讲明:
如上图所示,若是更新操做顺序执行,则数据的版本(version)依次递增,不会产生冲突。可是若是发生有不一样的业务操做对同一版本的数据进行修改,那么,先提交的操做(图中B)会把数据version更新为2,当A在B以后提交更新时发现数据的version已经被修改了,那么A的更新操做会失败。
2.乐观锁定的第二种实现方式和第一种差很少,一样是在须要乐观锁控制的table中增长一个字段,名称无所谓,字段类型使用时间戳(timestamp), 和上面的version相似,也是在更新提交的时候检查当前数据库中数据的时间戳和本身更新前取到的时间戳进行对比,若是一致则OK,不然就是版本冲突。
使用举例:以MySQL InnoDB为例
仍是拿以前的实例来举:商品goods表中有一个字段status,status为1表明商品未被下单,status为2表明商品已经被下单,那么咱们对某个商品下单时必须确保该商品status为1。假设商品的id为1。
下单操做包括3步骤:
1.查询出商品信息
select (status,status,version) from t_goods where id=#{id}
2.根据商品信息生成订单
3.修改商品status为2
update t_goods set status=2,version=version+1where id=#{id} and version=#{version};
那么为了使用乐观锁,咱们首先修改t_goods表,增长一个version字段,数据默认version值为1。
t_goods表初始数据以下:
对于乐观锁的实现,我使用MyBatis来进行实践,具体以下:
Goods实体类:
/** * ClassName: Goods <br/> * Function: 商品实体. <br/>*/public class Goods implements Serializable { /** * serialVersionUID:序列化ID. */ private static final long serialVersionUID = 6803791908148880587L; /** * id:主键id. */ private int id; /** * status:商品状态:1未下单、2已下单. */ private int status; /** * name:商品名称. */ private String name; /** * version:商品数据版本号. */ private int version; @Override public String toString(){ return "good id:"+id+",goods status:"+status+",goods name:"+name+",goods version:"+version; } //setter and getter}
GoodsDao
/** * updateGoodsUseCAS:使用CAS(Compare and set)更新商品信息 * @param goods 商品对象 * @return 影响的行数 */int updateGoodsUseCAS(Goods goods);
mapper.xml
<update id="updateGoodsUseCAS" parameterType="Goods"> <![CDATA[ update t_goods set status=#{status},name=#{name},version=version+1 where id=#{id} and version=#{version} ]]></update>
GoodsDaoTest测试类
@Testpublic void goodsDaoTest(){ int goodsId = 1; //根据相同的id查询出商品信息,赋给2个对象 Goods goods1 = this.goodsDao.getGoodsById(goodsId); Goods goods2 = this.goodsDao.getGoodsById(goodsId); //打印当前商品信息 System.out.println(goods1); System.out.println(goods2); //更新商品信息1 goods1.setStatus(2);//修改status为2 int updateResult1 = this.goodsDao.updateGoodsUseCAS(goods1); System.out.println("修改商品信息1"+(updateResult1==1?"成功":"失败")); //更新商品信息2 goods1.setStatus(2);//修改status为2 int updateResult2 = this.goodsDao.updateGoodsUseCAS(goods1); System.out.println("修改商品信息2"+(updateResult2==1?"成功":"失败")); }
输出结果:
good id:1,goods status:1,goods name:道具,goods version:1 good id:1,goods status:1,goods name:道具,goods version:1 修改商品信息1成功 修改商品信息2失败
说明:
在GoodsDaoTest测试方法中,咱们同时查出同一个版本的数据,赋给不一样的goods对象,而后先修改good1对象而后执行更新操做,执行成功。而后咱们修改goods2,执行更新操做时提示操做失败。此时t_goods表中数据以下:
mysql> select * from t_goods;+----+--------+------+---------+| id | status | name | version |+----+--------+------+---------+| 1 | 2 | 道具 | 2 || 2 | 2 | 装备 | 2 |+----+--------+------+---------+2 rows in setmysql>
咱们能够看到 id为1的数据version已经在第一次更新时修改成2了。因此咱们更新good2时update where条件已经不匹配了,因此更新不会成功,具体sql以下:
update t_goods set status=2,version=version+1where id=#{id} and version=#{version};
这样咱们就实现了乐观锁
悲观锁应用
须要使用数据库的锁机制,好比SQL SERVER 的TABLOCKX(排它表锁) 此选项被选中时,SQL Server 将在整个表上置排它锁直至该命令或事务结束。这将防止其余进程读取或修改表中的数据。
SqlServer中使用
Begin Tran select top 1 @TrainNo=T_NO from Train_ticket with (UPDLOCK) where S_Flag=0 update Train_ticket set T_Name=user, T_Time=getdate(), S_Flag=1 where T_NO=@TrainNo commit
咱们在查询的时候使用了with (UPDLOCK)选项,在查询记录的时候咱们就对记录加上了更新锁,表示咱们即将对此记录进行更新. 注意更新锁和共享锁是不冲突的,也就是其余用户还能够查询此表的内容,可是和更新锁和排它锁是冲突的.因此其余的更新用户就会阻塞.
参考:多版本并发控制