case-主从延迟问题排查

一、背景

突然有大量业务人员反馈，原有功能不好用。

二、解决过程

1. 查看数据状态

马上查询数据库查询发现该数据valid字段状态不正确，所以不能进行正常功能的操作。

2. 修复数据减少影响范围降低损失：

由于不是我负责的业务，所以马上查看代码逻辑。找到补救状态而且不影响后续流程的方法，并且确定查找问题的日志都齐全不用保留现场，马上进行操作补救。

三、问题分析

上一步是为了临时解决问题降低损失，接下来就要查找问题根源，彻底解决问题。

  1). 撸代码查日志

查看服务日志，发现日志表明数据库更新valid字段时成功了，而且后续也没有修改valid字段的操作。但是现在查却不是当时设置的状态。经过仔细的日志查找之后发现，对于这一条数据的更新只有一条两分钟之后的临近其他操作。马上找到这块逻辑代码，一段不可描述的代码出现在眼前：

这么写不会挨打吗？我解释一下，第一行从数据库查询而且是从库，第二、三行copy一下修改了一个值，第四行整体写回主库。因为是整体写回所以如果在这之间如果valid值被修改是会被覆盖回去的。这代码一看就特么有问题，哪怕都走主库都有问题。更何况这是主从分离的。

但是根据日志分析，上一次的更新是两分钟之前的，第一感觉不会这么大的延迟啊。但是日志也没有其他的更新了，不能排除有其他服务更新这条数据。

  2). 撸binlog

上一步的证据不足以说明任何问题，于是下载了主库binlog，经过分析binlog确认确实是这段代码造成的，valid值被修改后又被覆盖了回去。导致状态不正确。

  3). 撸DBA

DBA问了一下这么大的延迟什么情况？DBA说今天下午有个bug造成从库并发锁等待导致延迟超级超级大。。。

四、后续TODO

代码有问题改代码！写代码要多考虑并发情况。