Mysql数据库update操作死锁问题分析

简介

问题是这样的，我负责的一个线上模块的功能是给装有我们产品APP的手机设备根据业务功能打上特殊的推送标签。每个设备有多个不同的标签，每个标签下包括很多设备。由于用户在使用app时会触发很多逻辑，随时都可能有对标签的增删。包括一些辅助的脚本及离线算法计算结果，所以在同一段时间内可能存在针对同一个设备的一个标签进行修改的情况。
基于以上前提，我发现近期经常会报出一些数据库操作失败的错误，打印出mysql错误日志如下：

 1213 Deadlock found when trying to get lock; try restarting transaction

即触发了mysql的死锁错误。

由于我的业务使用的是Innodb存储引起，所以一般不会触发表所，这种情况大概率是行锁，下面是集中加锁触发情况。

经过查看日志发现，触发每次触发死锁的时候，那个时段都会有多次对相同设备更新标签的请求，尤其是同一个标签。由此可以猜测到，触发了Innodb的行锁。

进一步分析发现，当更新设备标签记录行时，where条件后的两个条件没有设置唯一索引，根基mysql加锁逻辑，此时可能会出现两个更新语句，分别获得了两个where条件的一个锁，都在等待对方持有的另一个锁，因此造成了死锁现象。

由于打标签逻辑走的是异步消费者队列kafka，众所周知kafka同一个topic的不同partition间没有时序，所以相同的设备，在不同的partition上就会出现顺序不可控现象。如果相同的设备都在同一个partition上等待消费就能保证先后顺序了。因此，我决定在生产消息时，把相同设备的消息放到相同的partition上，所以就不会出现同一段时间更新同一行记录的情况。所以问题解决了。

欢迎关注公众号『野狐』