+-
MySQL行级锁解决消费队列中出现的唯一主键错误
首页 专栏 mysql 文章详情
3

MySQL行级锁解决消费队列中出现的唯一主键错误

临_择 发布于 3 月 8 日
前言:最近项目中的定时任务消费队列一直出现一个重复的唯一主键错误,是多个事务对同一行数据进行操作引起的。解决这个问题后,我便写了这篇博客的草稿,由 ctx同学强势审核修改后,便有了这一版本的博客。

场景复现

出错方法:

@Transactional
public void handleAccountRisk(String accountUuid, float risk, RiskConfEtcdVo riskConf, Long currentTimeSeconds) {
    // 分布式锁
    String redisKey = RISK_UPDATE_LOCK_KEY.re~~~~place("${item}", accountUuid);
    String businessId = BusinessIdGeneratorUtil.businessId();
    redissonLockUtil.lock(redisKey,businessId, () -> {
        AccountRiskEntity accountRisk = accountRiskTplDao.getAccountRiskByUuid(accountUuid);
        // 如果accountRisk不存在则新增
        if (null == accountRisk) {
            // 实例化一个对象后填充...
            // insert
            accountRiskTplDao.save(target);
        // 如果存在则更新
        } else {
            ...
            accountRiskTplDao.updateById(accountRisk);
            ...
        }
    });
}

报错信息:

INSERT INTO account_risk  ( create_time, update_time, risk, uuid )  VALUES  ( ?, ?, ?,
com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: Duplicate entry 'dc57ktzmtiwp' for key 'uuid'   

问题分析

从Duplicate entry推断出重复插入。具体原因为:

多个事务在执行这个方法。
事务A:根据uuid查不到数据,实例化一个实体,insert,但还未提交事务
事务B:根据uuid查不到数据,实例化一个实体
此时 :A提交了事务,B执行insert
事务B:insert中出现报错: Duplicate entry 'dc57ktzmtiwp' for key 'uuid'

解决方案

根据上面的分析,主需要对指定uuid对应的行数据加锁,不允许多个事务同时对该行记录进行操作。
可以通过使用innodb行级锁来解决。

getAccountRiskByUuid方法的sql后面加上 for update:
public AccountRiskEntity getAccountRiskByUuid(String uuid){
    QueryWrapper<AccountRiskEntity> queryWrapper = new QueryWrapper<>();
    queryWrapper.eq("uuid",uuid);
    // 悲观锁
    queryWrapper.last("FOR UPDATE");
    return baseMapper.selectOne(queryWrapper);
}

相似场景

DDIA的第七章事务中,对这种情况有详细的举例描述。

关于InnoDB行锁

加锁方式

共享锁(S):select * from table_name where ... lock in share mode; 排他锁(X):select * from table_name where ... for update;

使用场景

如果遇到存在高并发并且对于数据的准确性很有要求的场景,是需要了解和使用for update的。 比如涉及到金钱、库存等。一般这些操作都是很长一串并且是开启事务的。如果库存刚开始读的时候是1,而立马另一个进程进行了update将库存更新为0了,而事务还没有结束,会将错的数据一直执行下去,就会有问题。所以需要for upate 进行数据加锁防止高并发时候数据出错。 记住一个原则:一锁二判三更新

InnoDb行锁的实现方式:

InnoDB行锁是通过给索引项加锁来实现的,如果没有索引,InnoDB将通过隐藏的聚簇索引来对记录枷锁。没有索引的话会退化成锁表!

幻读:指当前某个事务在读取某个范围内的记录时,另外一个事务又在该范围内插入了新的记录。当之前的事务再次读取该范围的记录时,会产生幻行。---《高性能Mysql》

个人理解:当我们依据(某个事务在读取某个范围内的记录)的结果作为判断条件决定后续的操作,在另一个事务(又在该范围内插入了新的记录)后,之前判断条件的结果就可能会被改变了。违背了这个判断条件,那么后续的操作就需要保持疑问了?

mysql
阅读 165 更新于 3 月 8 日
赞3 收藏
分享
本作品系原创, 采用《署名-非商业性使用-禁止演绎 4.0 国际》许可协议
avatar
临_择
1 声望
4 粉丝
关注作者
0 条评论
得票 时间
提交评论
avatar
临_择
1 声望
4 粉丝
关注作者
宣传栏
目录
前言:最近项目中的定时任务消费队列一直出现一个重复的唯一主键错误,是多个事务对同一行数据进行操作引起的。解决这个问题后,我便写了这篇博客的草稿,由 ctx同学强势审核修改后,便有了这一版本的博客。

场景复现

出错方法:

@Transactional
public void handleAccountRisk(String accountUuid, float risk, RiskConfEtcdVo riskConf, Long currentTimeSeconds) {
    // 分布式锁
    String redisKey = RISK_UPDATE_LOCK_KEY.re~~~~place("${item}", accountUuid);
    String businessId = BusinessIdGeneratorUtil.businessId();
    redissonLockUtil.lock(redisKey,businessId, () -> {
        AccountRiskEntity accountRisk = accountRiskTplDao.getAccountRiskByUuid(accountUuid);
        // 如果accountRisk不存在则新增
        if (null == accountRisk) {
            // 实例化一个对象后填充...
            // insert
            accountRiskTplDao.save(target);
        // 如果存在则更新
        } else {
            ...
            accountRiskTplDao.updateById(accountRisk);
            ...
        }
    });
}

报错信息:

INSERT INTO account_risk  ( create_time, update_time, risk, uuid )  VALUES  ( ?, ?, ?,
com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: Duplicate entry 'dc57ktzmtiwp' for key 'uuid'   

问题分析

从Duplicate entry推断出重复插入。具体原因为:

多个事务在执行这个方法。
事务A:根据uuid查不到数据,实例化一个实体,insert,但还未提交事务
事务B:根据uuid查不到数据,实例化一个实体
此时 :A提交了事务,B执行insert
事务B:insert中出现报错: Duplicate entry 'dc57ktzmtiwp' for key 'uuid'

解决方案

根据上面的分析,主需要对指定uuid对应的行数据加锁,不允许多个事务同时对该行记录进行操作。
可以通过使用innodb行级锁来解决。

getAccountRiskByUuid方法的sql后面加上 for update:
public AccountRiskEntity getAccountRiskByUuid(String uuid){
    QueryWrapper<AccountRiskEntity> queryWrapper = new QueryWrapper<>();
    queryWrapper.eq("uuid",uuid);
    // 悲观锁
    queryWrapper.last("FOR UPDATE");
    return baseMapper.selectOne(queryWrapper);
}

相似场景

DDIA的第七章事务中,对这种情况有详细的举例描述。

关于InnoDB行锁

加锁方式

共享锁(S):select * from table_name where ... lock in share mode; 排他锁(X):select * from table_name where ... for update;

使用场景

如果遇到存在高并发并且对于数据的准确性很有要求的场景,是需要了解和使用for update的。 比如涉及到金钱、库存等。一般这些操作都是很长一串并且是开启事务的。如果库存刚开始读的时候是1,而立马另一个进程进行了update将库存更新为0了,而事务还没有结束,会将错的数据一直执行下去,就会有问题。所以需要for upate 进行数据加锁防止高并发时候数据出错。 记住一个原则:一锁二判三更新

InnoDb行锁的实现方式:

InnoDB行锁是通过给索引项加锁来实现的,如果没有索引,InnoDB将通过隐藏的聚簇索引来对记录枷锁。没有索引的话会退化成锁表!

幻读:指当前某个事务在读取某个范围内的记录时,另外一个事务又在该范围内插入了新的记录。当之前的事务再次读取该范围的记录时,会产生幻行。---《高性能Mysql》

个人理解:当我们依据(某个事务在读取某个范围内的记录)的结果作为判断条件决定后续的操作,在另一个事务(又在该范围内插入了新的记录)后,之前判断条件的结果就可能会被改变了。违背了这个判断条件,那么后续的操作就需要保持疑问了?