mysql乐观锁总结和实践

上一篇文章《MySQL悲观锁总结和实践》谈到了MySQL悲观锁，但是悲观锁并不是适用于任何场景，它也有它存在的一些不足，因为悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。如果加锁的时间过长，其他用户长时间无法访问，影响了程序的并发访问性，同时这样对数据库性能开销影响也很大，特别是对长事务而言，这样的开销往往无法承受。所以与悲观锁相对的，我们有了乐观锁，具体参见下面介绍：

 

乐观锁介绍：

乐观锁（ 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+1

where id=#{id} and version=#{version};

 

那么为了使用乐观锁，我们首先修改t_goods表，增加一个version字段，数据默认version值为1。

t_goods表初始数据如下：

mysql> select * from t_goods;
+----+--------+------+---------+
| id | status | name | version |
+----+--------+------+---------+
|  1 |      1 | 道具 |       1 |
|  2 |      2 | 装备 |       2 |
+----+--------+------+---------+
2 rows in set

mysql>

对于乐观锁的实现，我使用MyBatis来进行实践，具体如下：

Goods实体类：

/**
 * ClassName: Goods <br/>
 * Function: 商品实体. <br/>
 * date: 2013-5-8 上午09:16:19 <br/>
 * @author [e-mail]
 */
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)更新商品信息. <br/>
 *
 * @author [e-mail]
 * @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测试类

@Test
public 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 set

mysql> 

我们可以看到 id为1的数据version已经在第一次更新时修改为2了。所以我们更新good2时update where条件已经不匹配了，所以更新不会成功，具体sql如下：

update t_goods 
set status=2,version=version+1
where id=#{id} and version=#{version};

这样我们就实现了乐观锁

 

以上就是我对MySQL乐观锁的总结和实践，写得比较浅显，有不对的地方欢迎拍砖

评论

17 楼 hayoouch 2018-01-19  

XieFuQ 写道

既然都考虑到乐观锁了，是否可以直接换表存储引擎为MyISAM。

都5.7了，myisam还有什么优势

16 楼 XieFuQ 2018-01-04  

既然都考虑到乐观锁了，是否可以直接换表存储引擎为MyISAM。

15 楼 sqy 2017-08-28  

问下大神，我想做版本控制，但是为了数据一致性，我想2个修改过来的话，而不是1成功，2失败，我要两个都成功，并且这个数据是正确的，没有脏读

14 楼 咖啡涩lr 2017-03-04  

尹鹏波 写道

学习了，多谢楼主分享

GoodsDaoTest测试类中的第19行应该是 goods2 吧？

13 楼 咖啡涩lr 2017-03-04  

wellse 写道

大家都用过SVN吧，也就是这样的乐观锁机制。大家可以联想起来就明白了。

GoodsDaoTest测试类中的第19行应该是 goods2 吧？

12 楼 wellse 2016-12-21  

大家都用过SVN吧，也就是这样的乐观锁机制。大家可以联想起来就明白了。

11 楼 尹鹏波 2016-04-22  

学习了，多谢楼主分享

10 楼 a953924393 2015-11-02  

乐观锁使用版本号来判断是否是已经更新过的数据, 那比如我有一个商品表的库存, 可能需要频繁的更新, 而商品详情的更新不频繁, 当更新详情时再更新库存, 其实没关系的, 但是因为版本号变化了, 所以更新库存不成功. 在你举得这个例子中, 我觉得是不是使用update t_goods
set status=2
where id=#{id} and status = 1; 是不是就解决问题了?

9 楼 zhidanos 2014-08-20  

非常不错，解决了我很多问题

8 楼 chenzhou123520 2013-09-24  

我叫张恒 写道

呵呵 我在处理DJ的同时下单问题。看到了你的博文之后，我就问了下之前，原来ＴＬ中的那个模块　就是你做的！呵呵　收益匪浅。。

呵呵，以前写的代码，估计可优化的空间很大，包括天龙应该也是。你有时间可以review一下，做下优化

7 楼 我叫张恒 2013-09-24  

呵呵 我在处理DJ的同时下单问题。看到了你的博文之后，我就问了下之前，原来ＴＬ中的那个模块　就是你做的！呵呵　收益匪浅。。

6 楼 chenzhou123520 2013-05-12  

welon123 写道

通俗易懂，赞一个

谢谢鼓励

5 楼 welon123 2013-05-12  

通俗易懂，赞一个

4 楼 chenzhou123520 2013-05-09  

MrCrapBag 写道

有点疑惑：
version对于更新条件中缺少主键信息的情况，就不可行了吧?

这个不一定吧，如果除了主键之外还有能够唯一标识数据记录的字段也可以当做where条件的判断条件啊。

3 楼 MrCrapBag 2013-05-09  

有点疑惑：
version对于更新条件中缺少主键信息的情况，就不可行了吧?

2 楼 chenzhou123520 2013-05-08  

darkness_t 写道

很容易理解`~

写得比较浅，希望能帮到大家

1 楼 darkness_t 2013-05-08  

很容易理解`~