Loading... > 前言：项目中定时任务模块出现的问题，记录人还是[哲哥](https://segmentfault.com/u/linzhe_5f715361ed8c9)，由本人强势审核。 <!--more--> ## 问题描述 最近项目中的定时任务消费队列一直出现一个重复的唯一主键错误，是多个事务对同一行数据进行插入操作引起的。 ## 场景复现 **出错方法：** ```java @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); ... } }); } ``` **报错信息：** ```sql 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`: ```java 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无法再现前一次读取结果。具体地讲，不可重复读包括三种情况:<br>(1)**改：**事务T1读取某一数据后，事务T2对其进行了修改，当事务T1再次读该数据时，得到与前一次不同的值。例如在图11.2(b)中，T1读取B=100进行运算,T2读取同一数据B,对其进行修改后将B=200写回数据库。T为了对读取值校对重读B，B已为200，与第一次读取值不一致。<br>(2)**删：**事务T1按一定条件从数据库中读取了某些数据记录后，事务T2删除了其中部分记录，当T1再次按相同条件读取数据时，发现某些记录神秘地消失了。<br>(3)**增：**事务T1按一定条件从数据库中读取某些数据记录后，事务T2插入了一些记录，当T1再次按相同条件读取数据时,发现多了一些记录。<br>后两种不可重复读有时也称为**幻影/幻读（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，与数据库内容不一致，就是“脏”数据。  产生上述三类数据不一致性的主要原因是并发操作破坏了事务的**隔离性**。**并发控制机制就是要用正确的方式调度并发操作，使一个用户事务的执行不受其他事务的干扰**，从而避免造成数据的不一致性。 另一方面，对数据库的应用有时允许某些不一致性，例如有些统计工作涉及数据量很大，读到一些“脏”数据对统计精度没什么影响，这时可以降低对一致性的要求以减少系统开销。 **并发控制的主要技术有封锁(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：August 21, 2022 © Allow specification reprint Like 0 喵ฅฅ
One comment
滴滴