并发事务死锁问题排查
业务系统上线后，服务日志报错:
Jul 20 15:10:30 xxx: {"level":"error","error":"Error 1213: Deadlock found when trying to get lock; try restarting transaction","time":"2021-07-20T15:10:35.845197649+08:00","message":"error delete entities before insert"}
上游业务系统监听多个topic，但不同topic有交集，交集为共同更新我们系统的某一张表。服务虽然一直在报错，但是数据并没有出现重复及丢失的情况。针对这个问题现象进行排查。
1 排查思路：
1.1 首先调研下mysql InnoDB锁的详细说明：
概念:
共享锁(S Lock)：允许事务读一行数据，多个事务可以并发对某一行数据加S Lock
排他锁(X Lock): 允许事务删除或更新一行数据，只有行数据没有任何锁才可以获取X Lock
共享锁和排他锁，就是我们日常见到的读锁和写锁。一个线程加了读锁，其他线程如果是读取数据，也可以加读锁继续读取。而一旦有一个线程需要加写锁，前提是该数据没有加锁，如果当前数据已经加了读锁或者写锁，当前线程必须等到锁释放，才可以加写锁。
共享锁和排他锁，在InnoDB中对应的是行级别锁。但是InnoDB除了支持共享锁(S Lock)和排他锁(X Lock)，还支持表级别的两把锁，意向共享锁(IS Lock)和意向排他锁(IX Lock)，意向共享锁和意向排他锁虽然是表级别的锁实际应用在行级锁之中，用来锁定一个小范围。IS Lock事务想要获得一张表中某几行的共享锁; IX Lock事务想要获得一张表中某几行的排他锁
- 行锁 ：锁定一行数据，即我们常见的共享锁和排查锁
- 间隙锁：锁定一个范围，但不包含记录本身。例如数据库中id为3，8，11，那么锁定的区间可能为(-∞, 3), (3, 8), (8, 11), (11, +∞)。假如插入的数据id为6，那么此时锁定的区间为(3, 6), (6, 8)被锁定，不包括要插入的6
- 行锁 + 间隙锁：锁定一个范围，包括记录本身。例如数据库中id为3，8，11，那么锁定的区间可能为(-∞, 3], (3, 8], (8, 11], (11, +∞]。那么假如插入id为6的数据，此时锁定的区间为(3, 6], (6, 8]两个部分，可以看到，6也被锁定了。
1.2 间隙锁有什么用？
我们了解了MySQL的InnoDB的常见锁，了解了表级别间隙锁会应用在行级别的范围之中。那么间隙锁有什么好处。
我们应该听说过幻读，即在同一事务下，连续执行两次同样的SQL语句可能导致不同的结果，第二次的SQL语句可能返回之前不存在的行。InnoDB使用行锁 + 间隙锁的方式解决这个问题。当然，InnoDB存储引擎在查询数据时是不存在锁的，这是因为查询的数据来自于快照版本，即历史数据。
1.3 MySQL常见操作对锁的应用
- Insert操作：数据库插入一行数据时，需要获取行锁
- Update操作：更新一条记录时，如果记录存在，需要行锁，如果不存在，需要行锁+间隙锁。
- Delete操作：删除一条记录时，如果记录存在，需要行锁；如果记录不存在，行锁+间隙锁。
- Select操作：不会加锁，因为查询的数据主要来自于快照版本，即历史数据。除非显示的调用lock share mode或for update。
-- 显示的为查询添加共享锁S Lock
select * from a where id = 1 lock in share mode ;
-- 显示的为查询添加排他锁X Lock
select * from a where id = 1 for update ;
1.4 服务为啥会Deadlock
通过前期对Mysql InnoDB锁相关资料的了解，分析我们系统为啥会出现大量的deadlock日志报错。
Jul 20 15:10:30 xxx: {"level":"error","error":"Error 1213: Deadlock found when trying to get lock; try restarting transaction","time":"2021-07-20T15:10:35.845197649+08:00","message":"error delete entities before insert"}
造成死锁竞争状态后，mysql会将优先的事务提交，另一个事务释放锁，然后抛出报错信息。
2 解决思路
并发情况下减少delete-insert事务操作
可以回避这种在事务中，delete-insert多线程操作的问题，例如我们可以先查数据是否存在，不存在不执行delete操作，避免不存在执行delete操作，触发mysql的行锁+间隙锁机制。如果存在我们delete，只会用到mysql的行锁。这就一定程度上避免了锁竞争无法释放的问题。但是这样操作也会存在一定的风险，是否可以软删除，避免高并发情况下，出现数据已经被删除，而其他事物正在删除不存在的数据问题。
单进程下可考虑在事务上加锁
sessionA和sessionB两个事务，在竞争的情况下，删除了不存在的记录，会触发mysql的行锁+间隙锁。主要出发点在于，与其在mysql竞争间隙锁的过程中报错，然后事务回滚，资源大量浪费，不如在进入事务之前进行并发控制。虽然锁的粒度有点粗，但是相对于事务一直回滚，服务端不停打印错误日志，是更能接受的。
多进程高可用的情况
对于高可用多进程情况，可以通过分布式锁结局。如果不想借助非mysql的外部锁结局，那么也可以考虑对delete-insert事务进行排序，加入有序队列中，挨个消化。这实质上也是变相做了同步操作。
思考方向：尽可能避免触发mysql的间隙锁。
3 最终解决办法
单进程加了一个锁，对多线程的delete-insert事务，同步处理。
// 对线程并发调用的方法
func (ei entitiesImpl) UpsertEntitis(ctx context.Context, id string, entities model.Entities) error {
conn, err := DB.Conn(ctx)
if err != nil {
return err
}
defer conn.Close()
// 对delete-insert做同步处理
entityMux.Lock()
defer entityMux.Unlock()
tx, err := conn.BeginTx(ctx, &sql.TxOptions{})
if err != nil {
return nil
}
res, err := tx.ExecContext(ctx, "delete from entities where id = ?", id)
if err != nil {
tx.Rollback()
return err
}
_, _ = res.RowsAffected()
for _, v := range entities {
_, err := tx.ExecContext(ctx, "INSERT INTO entities (`id`) VALUES (?)",v.id)
if err != nil {
tx.Rollback()
return err
}
}
tx.Commit()
huskar.Debug(ctx).Int("entities_size", len(entities)).Msg("insert new entities")
return nil
}