MySQL 技巧:如何实现乐观锁?

使用 MySQL 5.7 做测试,数据库引擎为 InnoDB,数据库隔离级别为可重复读(REPEATABLE-READ),读读共享,读写互斥。在这个隔离级别下,在多事务并发的情况下,还是会出现数据更新的冲突问题。

先分析一下更新冲突的问题是如何产生的。

假设我们有一张销量表 goods_sale ,表结构如下:

字段 数据类型 说明
goods_sale_id varchar(32) 销量 id
goods_id varchar(32) 商品 id
count int(11) 销量

比如在某一时刻事务 A 和事务 B,在同时操作表 goods_sale 的 goods_id = 20191017344713049535651840506935 的数据,当前销量为 100。

goods_sale_id goods_id count
20191017344778600995856384326638 20191017344713049535651840506935 100

两个事务的内容一样,都是先读取的数据,count +100 后更新。

我们这里只讨论乐观锁的实现,为了便于描述,假设项目已经集成 Spring 框架,使用 MyBatis 做 ORM,Service 类的所有方法都使用了事务,事务传播级别使用 PROPAGATION_REQUIRED ,在事务失败会自动回滚。

Service 为 GoodsSaleService ,更新数量的方法为 addCount()

@Service
@Transaction
pubic class GoodsSaleService  {
    
    @Autowire
    private GoodsSaleDao dao;
    
    public void addCount(String goodsId, Integer count) {
        GoodsSale goodsSale = dao.selectByGoodsId(goodsId);
        if (goodsSale == null) {
            throw new Execption("数据不存在");
        }
        int count = goodsSale.getCount() + count;
        goodsSale.setCount(count);
        int count = dao.updateCount(goodsSale);
        if (count == 0) {
            throw new Exception("添加数量失败");
        }
    }
    
}

使用的 Dao 为 GoodsSaleDao ,有两个方法

public interface GoodsSaleDao {
    
    GoodsSale selectByGoodsId(@Param("goodsId") String goodsId);
    
    int updateCount(@Param("record") GoodsSale goodsSale);
}

mapper 文件对应的 sql 操作为:

<!-- 查询 -->
<select id="selectByGoodsId" resultMap="BaseResultMap">
    select
    <include refid="Base_Column_List"/>
    from goods_sale
    where goods_id = #{goodsId}
</select>

<!-- 更新 -->
<update id="updateCount">
    update
    goods_sale
    set count = #{record.count},
    where goods_sale_id = #{record.goodsSaleId}
</update>

好了,假设现在有两个线程同时调用了 GoodsSaleService#addCount ,操作同一行数据,会有什么问题?

假设这两个线程对应的事务分为事务 A 和事务 B。用一张流程图来说明问题:

MySQL-多事务更新冲突

更新冲突了!两次 addCount(100) ,结果应该是 300,结果还是 200。

该如何处理这个问题,有一个简单粗暴的方法,既然这里多线程访问会有线程安全问题,那就上锁,方法加入 synchronized 进行互斥。

public synchronized void addCount(String goodsId, Integer count) {
    ...
}

这个方案确实也可以解决问题,但是这种简单互斥的做法,锁的粒度太高,事务排队执行,并发度低,性能低。但如果是分布式应用,还得考虑应用分布式锁,性能就更低了。

考虑到这些更新冲突发生的概率其实并不高。这里讨论另一种解决方案,使用乐观锁来实现。原理就是基于 CAS ,比较并交换数据,如果发现被更新过了,直接更新失败。然后加入自旋(自循环)接着更新,直到成功。乐观就在于我们相信冲突发生概率低,如果发生了,就用一种廉价的机制迅速发现,快速失败。

我们来讨论如何实现它。数据库表 GoodsSale 新增一行 data_version 来记录数据更新的版本号。新的表结构如下:

字段 数据类型 说明
goods_sale_id varchar(32) 销量 id
goods_id varchar(32) 商品 id
count int(11) 销量
data_version int(11) 版本号

GoodsSaleDao#updateCount 对应的 mapper 的 SQL 语句进行调整,数据更新的时候同时进行 data_version = data_version + 1 ,执行这个 sql 时候已经对数据上行锁了,所以这个 data_version 加 1 的操作为原子操作。

<!-- 乐观锁更新 -->
<update id="updateCount">
    update
    goods_sale
    set count = #{record.count}, data_version = data_version + 1
    where goods_sale_id = #{record.goodsSaleId}
    and data_version = #{record.dataVersion}
</update>

Dao 调整之后,事务 A 和事务 B 的变化如下:

MySQL-多事务更新冲突-加锁

有了发现冲突快速失败的方案,要想让更新成功,可以在 GoodsSaleService 中加入自旋,重新开始事务业务逻辑的执行,直到没有发生冲突,更新成功。自旋的实现有两种,一种是使用循环,一种是使用递归。

循环实现:

public void addCount(String goodsId, Integer count) {
    while(true) {
        GoodsSale goodsSale = dao.selectByGoodsId(goodsId);
        if (goodsSale == null) {
            throw new Execption("数据不存在");
        }
        int count = goodsSale.getCount() + count;
        goodsSale.setCount(count);
        int count = dao.updateCount(goodsSale);
        if (count > 0) {
            return;
        }   
    }
}

递归实现:

public void addCount(String goodsId, Integer count) {
    GoodsSale goodsSale = dao.selectByGoodsId(goodsId);
    if (goodsSale == null) {
        throw new Execption("数据不存在");
    }
    int count = goodsSale.getCount() + count;
    goodsSale.setCount(count);
    int count = dao.updateCount(goodsSale);
    if (count == 0) {
        addCount(goodsId, count)
    }
}

通过乐观锁+自旋的方式,解决数据更新的线程安全问题,而且锁粒度比互斥锁低,并发性能好。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 151,511评论 1 330
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 64,495评论 1 273
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 101,595评论 0 225
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 42,558评论 0 190
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 50,715评论 3 270
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 39,672评论 1 192
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,112评论 2 291
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 29,837评论 0 181
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 33,417评论 0 228
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 29,928评论 2 232
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,316评论 1 242
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 27,773评论 2 234
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,253评论 3 220
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 25,827评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,440评论 0 180
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 34,523评论 2 249
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 34,583评论 2 249

推荐阅读更多精彩内容