记一次replace into引发的死锁问题

记一次replace into引发的死锁问题 记一次replace into引发的死锁问题

需求是使用kafka监听历史表的变动，写入到新表之中。写数据的核心代码用到了mysql 的 replace into

public hanlde(DebeziumEventRecord record){
 ...
 TradeMapper mapper = sqlSession.getMapper(TradeMapper.class);
 int result = mapper.replace(trade);
 ...
}

测试环境运行正常。部署生产环境之后，就观察到了死锁日志

org.springframework.dao.DeadlockLoserDataAccessException: 
Error updating database.  Cause: com.mysql.cj.jdbc.exceptions.MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction

网上检索资料推测是replace into并发修改同一条数据记录引起的死锁。因为只是临时监听代码，就简单的在修改记录时加上了分布式锁。

public hanlde(DebeziumEventRecord record){
 ...
 DistLock distLock = distLockFactory.build("TRADE_LOCK_KEY_" + trade.getTradeNo());
 distLock.tryAcquire();
 TradeMapper mapper = sqlSession.getMapper(TradeMapper.class);
 int result = mapper.replace(trade);
 distLock.release();
 ...
}

部署之后，没过一会产线继续收到死锁的报错日志。已知分布式锁的实现没有问题，那么就代表死锁原因并不是并发修改同一条记录引起的。
怀疑是不是只要同时进行多个replace into *** 作就会引起死锁呢。写了一个简单的python脚本并多开进行实验(python是伪多线程)。

 cursor.execute("replace into LockTest (id,value) values (1, 2);")

多个进程长时间运行未发生死锁。认为可能是表数据太少执行太快没有发生，对表填充数据后依然无死锁发生。可以初步推断只是并发进行同一张表的replace into并不会发生死锁。诱发死锁还需要一个限定条件。
查询相关资料，https://www.jianshu.com/p/497fd78f0b91。文中提到replace into即会对主键加Gap锁，又会对唯一索引加next key锁。那么死锁应该是并发执行时分别获取到部分锁引起的。

cursor.execute("replace into LockTest (id,value) values (1, 2);")

cursor.execute("replace into LockTest (id,value) values (2, 2);")

实验在不同客户端中并发修改不同的数据，此时终于复现了死锁，换成insert … on duplicate key则无此问题。
结论：replace into不适宜在产线环境大规模使用，如有需要考虑使用insert … on duplicate key