突然有大量业务人员反馈，原有功能不好用。
1. 查看数据状态
马上查询数据库查询发现该数据valid字段状态不正确，所以不能进行正常功能的操作。
2. 修复数据减少影响范围降低损失：
由于不是我负责的业务，所以马上查看代码逻辑。找到补救状态而且不影响后续流程的方法，并且确定查找问题的日志都齐全不用保留现场，马上进行操作补救。
上一步是为了临时解决问题降低损失，接下来就要查找问题根源，彻底解决问题。
1). 撸代码查日志
查看服务日志，发现日志表明数据库更新valid字段时成功了，而且后续也没有修改valid字段的操作。但是现在查却不是当时设置的状态。经过仔细的日志查找之后发现，对于这一条数据的更新只有一条两分钟之后的临近其他操作。马上找到这块逻辑代码，一段不可描述的代码出现在眼前：
这么写不会挨打吗？我解释一下，第一行从数据库查询而且是从库，第二、三行copy一下修改了一个值，第四行整体写回主库。因为是整体写回所以如果在这之间如果valid值被修改是会被覆盖回去的。这代码一看就特么有问题，哪怕都走主库都有问题。更何况这是主从分离的。
但是根据日志分析，上一次的更新是两分钟之前的，第一感觉不会这么大的延迟啊。但是日志也没有其他的更新了，不能排除有其他服务更新这条数据。
2). 撸binlog
上一步的证据不足以说明任何问题，于是下载了主库binlog，经过分析binlog确认确实是这段代码造成的，valid值被修改后又被覆盖了回去。导致状态不正确。
3). 撸DBA
DBA问了一下这么大的延迟什么情况？DBA说今天下午有个bug造成从库并发锁等待导致延迟超级超级大。。。
代码有问题改代码！写代码要多考虑并发情况。
