前言:项目中定时任务模块出现的问题,记录人还是哲哥,由本人强势审核。

问题描述

最近项目中的定时任务消费队列一直出现一个重复的唯一主键错误,是多个事务对同一行数据进行插入操作引起的。

场景复现

出错方法:

@Transactional(rollbackFor =Exception.class,
        propagation = Propagation.REQUIRES_NEW,
        isolation= Isolation.REPEATABLE_READ
)
public void handleAccountRisk(String accountUuid, float risk, RiskConfEtcdVo riskConf, Long currentTimeSeconds) {
    // 分布式锁
    String redisKey = RISK_UPDATE_LOCK_KEY.replace("${item}", accountUuid);
    String businessId = BusinessIdGeneratorUtil.businessId();
    redissonLockUtil.lock(redisKey,businessId, () -> {
        AccountRiskEntity accountRisk = accountRiskTplDao.getAccountRiskByUuid(accountUuid);
        // 如果accountRisk不存在则新增
        if (null == accountRisk) {
            // new一个target对象并填充
            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);
}

相似场景

并发控制概述

事务是并发控制的基本单位。
下面从课本中的样例再回顾一下:幻读脏读不可重复读

考虑飞机订票系统中的一个活动序列:
①甲售票点(事务T1)读出某航班的机票余额A,设A=16。
②乙售票点(事务T2)读出同一航班的机票余额A,也为16。
③甲售票点卖出一张机票,修改余额A=A-1,所以A为15,把A写回数据库。
④乙售票点也卖出一张机票,修改余额A=A-1,所以A为15,把A写回数据库。
结果明明卖出两张机票,数据库中机票余额只减少1。

这种情况称为数据库的不一致性。这种不一致性是由并发操作引起的。在并发操作情况下,对T1、T2两个事务的操作序列的调度是随机的。若按上面的调度序列执行,T1事务的修改就被丢失。这是由于第4步中T2事务修改A并写回后覆盖了T1事务的修改。
下面把事务读数据x记为R(x),写数据x记为W(x)。
并发操作带来的数据不一致性包括丢失修改、不可重复读和读“脏”数据。

  1. 丢失修改(lost update)
    两个事务T1和T2读入同一数据并修改,T2提交的结果破坏了T1提交的结果,导致T1的修改被丢失,如图11.2(a)所示。本例的飞机订票例子就属此类。
  2. 不可重复读(non-repeatable read)
    不可重复读是指事务T1读取数据后,事务T2执行更新操作,使T1无法再现前一次读取结果。具体地讲,不可重复读包括三种情况:
    (1)改:事务T1读取某一数据后,事务T2对其进行了修改,当事务T1再次读该数据时,得到与前一次不同的值。例如在图11.2(b)中,T1读取B=100进行运算,T2读取同一数据B,对其进行修改后将B=200写回数据库。T为了对读取值校对重读B,B已为200,与第一次读取值不一致。
    (2)删:事务T1按一定条件从数据库中读取了某些数据记录后,事务T2删除了其中部分记录,当T1再次按相同条件读取数据时,发现某些记录神秘地消失了。
    (3)增:事务T1按一定条件从数据库中读取某些数据记录后,事务T2插入了一些记录,当T1再次按相同条件读取数据时,发现多了一些记录。
    后两种不可重复读有时也称为幻影/幻读(phantom row)现象。
  3. 读“脏”数据(dirty read)
    读“脏”数据是指事务T1修改某一数据并将其写回磁盘,事务T2读取同一数据后,T1由于某种原因被撤销,这时被T1修改过的数据恢复原值,T2读到的数据就与数据库中的数据不一致,则T2读到的数据就为“脏”数据,即不正确的数据。例如在图11.2(c)中T1将C值修改为200,T2读到C为200,而T1由于某种原因撤销,其修改作废,C恢复原值100,这时T2读到的C为200,与数据库内容不一致,就是“脏”数据。

图11.2 三种数据不一致示例

产生上述三类数据不一致性的主要原因是并发操作破坏了事务的隔离性并发控制机制就是要用正确的方式调度并发操作,使一个用户事务的执行不受其他事务的干扰,从而避免造成数据的不一致性。
另一方面,对数据库的应用有时允许某些不一致性,例如有些统计工作涉及数据量很大,读到一些“脏”数据对统计精度没什么影响,这时可以降低对一致性的要求以减少系统开销。
并发控制的主要技术有封锁(locking)、时间戳(timestamp)、乐观控制法( optimisticscheduler)和多版本并发控制(multi-version concurrency control,MVCC)等。

关于InnoDB行锁

InnoDB行锁类型

  • 排他锁(X):又称为写锁。事务T对行数据加上写锁,则只允许T对其进行读取和修改,其他任何事务在该锁释放前都不能对其加锁或进行读取和修改
  • 共享锁(S):又称为读锁。事务T对行数据加上读锁,则T可以读A但不能修改,其他事务在该锁释放前只能对其加读锁和进行读取

加锁方式

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

使用场景

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

InnoDb行锁的实现方式:

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

Last modification:June 5th, 2021 at 11:39 pm
喵ฅฅ