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

编程并不是一个机械性的工作，而是需要有思考，有创新的工作，语法是固定的，但解决问题的思路则是依靠人的思维，这就需要我们坚持学习和更新自己的知识。今天golang学习网就整理分享《MySQL行级锁解决消费队列中出现的唯一主键错误》，文章讲解的知识点主要包括MySQL，如果你对数据库方面的知识点感兴趣，就不要错过golang学习网，在这可以对大家的知识积累有所帮助，助力开发能力的提升。

前言：最近项目中的定时任务消费队列一直出现一个重复的唯一主键错误，是多个事务对同一行数据进行操作引起的。解决这个问题后，我便写了这篇博客的草稿，由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中出现报错：

public AccountRiskEntity getAccountRiskByUuid(String uuid){
    QueryWrapperDDIA的第七章事务中，对这种情况有详细的举例描述。
关于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行级锁解决消费队列中出现的唯一主键错误》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多数据库知识！