高并发下修改db导致的生产故障！

发表于 2年以前 | 总阅读数：528 次

最近因为工作调整原因，被老大调取了新的部门干活，新部门的qps比较高，整体系统的复杂度也较之前提升了不少。刚入职没多久就遇到了一个生产环境的bug，闲话不多说，下边介绍下这个bug的背景。

Bug产生背景

用户在修改了个人资料信息之后，调用修改接口updateUserInfo去更新数据库的信息。在执行了update sql之后，将用户的缓存信息给移除了。当用户重新查询基础资料的时候会先到缓存查询，如果缓存不存在就从db中加载。整体的流程如下：

这类方案看起来似乎没有什么问题，但是在随着数据库架构变得越发复杂的情况下就不一定靠谱了。

由于线上环境采用的DB是主从模式，且通过监控发现updateUserInfo接口的tps较高，当修改用户信息接口在删除缓存之后，此时立马有请求去执行查询操作，此时会从db的从数据库中查询。由于数据库的主从延迟的问题，此时从数据库并没有那么快就有修改后的数据产生，因此从从库中查询的数据还是老数据，最终导致被查询出来的是修改前的记录并且还被重新放入到了缓存中。

虽然这是个小概率事件，但是工程师们还是希望尽可能避免这类bug发生。于是大家便各自给出了自己的解决方案。

延迟双删

在修改接口中加入双重删除缓存的操作，大致的伪代码如下：


boolean updateUserInfo(UserInfo userInfo){
   updateDb(userInfo);
   delCache(userInfo);
   //睡眠个0.5秒然后将第二次读未同步的从库而生成的缓存删除
   Thread.sleep(500);
   delCache(userInfo);
}

这种实现方案提出后直接被打回了，因为updateUserInfo接口是一个高并发访问接口，这么搞直接会把生产接口搞超时，而且这个sleep函数的时长也不好把握，万一主从延迟超过了500ms，双删也没有用。

既然同步双删会堵塞而且不好处理，那么异步双删可以吗？

异步双删有几种策略解决：

将第二次删除缓存的操作放入线程池中，异步等待睡眠个1秒后删除缓存。这种方案虽然不再堵塞主线程了，但是在高并发场景下分分钟就直接将线程池搞挂了，所以也被打回了。
接入一套我们自研的延迟回调组件，间隔1秒之后回调删除缓存的函数。这种方案似乎可以尝试，但是接入延迟回调组件可能会增加日后系统的复杂程度。
将需要被删除的缓存key存放在一条redis的zset队列中（score是放入的时间戳），然后开启一个定时任务将zset中最近1秒内放入的元素进行删除。这种方案看起来可以，但是在落地过程中会发现redis的zset长度是一个问题。如果并发量一旦打了，redis中说不定就会有bigkey的产生，为了避免bigkey还要去做拆key，这就越搞越复杂了。

在给出了多种设计方案之后，我们都发现通过双重删除的方式存在一个问题，就是无形中加大了对redis的访问量。该接口本身就是高并发接口，不必要的双重访问反而让redis的负载量更加大了，于是便尝试了其他的思路。

手动写入缓存

在更新了用户信息之后，手动将缓存信息写入到redis。这种方案看起来似乎是可以解决现有的问题，但是却忽略了一个问题，修改后的数据如果后期并没有需要访问的必要，是否还有必要去将它存入缓存呢？

在对现有的业务场景进行了一番分析之后，最终也是没有采用这种方案。

强制查询主数据库

当用户修改db之后，照样是先更新db，删除缓存。然后接下来的查询操作是优先从主db查询，再去加载到缓存。

这种技术实现方案的改动点目前来看是最小的，但是我们却意识到大量请求同时访问主db，会给db带来不小的压力。于是乎我们便开始分析为什么updateUserInfo的流量会如此之大。

在结合业务场景分析之后，发现高频率的写操作是发生在了一个记录用户最近活跃时间的字段（lastLoginTime）上，而这个字段在大部分的访问场景中几乎没有实际的使用，主要是一些后台定时任务中会使用。但是正是因为写代码的人没有意识到这一点，在频繁调用updateUserInfo函数的时候造成了缓存的频繁更新，从而导致了读出旧数据的问题发生。

于是我们尝试将updateUserInfo的逻辑拆解为了updateUserInfo和updateUserLastLoginTime两个方法。