记一次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