程序员：这个WebApi接口很奇葩，删除的数据几秒内还可以查出来！

程序员小伙伴诧异得跟我说：“哥，我数据都删了，结果还是能查到，但是再查就没有了，这是咋回事？”，问题是这样的，我们公司有个程序员小伙伴在调一个WebApi的删除接口后，立马又调用了这个WebApi的数据获取接口，结果发现，删除的数据还是会通过数据获取接口返回过来，但是只要等那么几秒再获取数据，就不会有，这是咋回事呢？

我看了下同事的代码，发现写的好像没有问题。然后我就下了几个断点去监视代码执行过程，最终确认了我的同事代码写得就是没有问题！

简单说下我同事代码的调用流程吧，首先有个数据查询按钮，根据条件访问WebApi把数据查出来以后，每条数据有一条ID，选中对应数据后，调用删除WebApi接口，传参数据ID，等待接口返回删除成功的消息，在收到删除成功的消息以后，再次调用查询按钮的逻辑根据原有条件再查询一遍，目的是为了刷新界面数据。

这么干应该没有多大问题吧？

但是，当再次调用查询按钮查出来的数据里面仍然有之前删除的数据，你们说奇怪不奇怪？

在确定我同事的代码没有问题以后，我大胆猜测，这个WebApi的删除接口肯定写得有问题！因为我们是调用的第三方接口，看不到源码，所以只能猜它为什么会这样。

聪明的小伙伴们，你们觉得是什么原因导致出现了这样的问题呢？

我猜这个第三方接口的数据查询接口，查询的实际上是缓存。而在每次增删改查以后，接口会更新缓存。

这个操作本来是没有问题的，但是，写删除接口的人可能犯了一个比较严重的错误。

我猜，过程是这样的，在接口收到数据ID以后，直接操作数据库执行语句，将数据库数据删除了，而不是先删除缓存。

这样做其实是没有问题的，因为可能存在一种情况，那就是如果先删除缓存的话，数据库数据删除失败了，那么缓存就恢复不了了。所以，先删数据库，再删除缓存一点毛病也没有。

但是，当数据库数据删除完成以后，需要更新缓存，此时，可能会存在两种操作，第一种就是直接从缓存里把数据删除，第二种就是把数据重新查一遍，再更新缓存。

我猜这个WebApi接口的提供者选择的是第二种方法！

但是，第二种方法有个缺点，那就是当数据量较大的话，重新查询数据可能会导致这个删除接口的等待时间过长。

于是，写这个接口的大聪明就直接选择了异步查询，并且不等待查询结果出来，就把接口结果抛出去了。

最终导致的结果就像我同事遇到的那样，当我的同事调用删除接口以后，接口先删除了数据库数据，然后异步且不等待执行了缓存更新逻辑，但是，可能数据库数据量较大，在缓存还没更新的情况下，我同事又再次调用了一下查询接口，而这个接口的数据因为是从未更新的缓存里面取的，所以，仍然可以查到已经删除的数据！

当有了这个猜想以后，我就开始找茬了，发现这个第三方平台提供的很多接口都是这个逻辑，不光是删除接口有问题，只要和增删改有关的接口几乎都会有问题。

比如说，增加完数据以后立马调用查询接口，发现刚刚增加的数据查不到，或者刚刚更新的数据再次查询发现根本没改，以及删除后还能查到的问题。

而只要过那么几秒再去查或者多查几次，这些问题就不会出现了！

最后，我联系了这个第三方平台接口的提供者，并且反馈了我们发现的问题，相信不久之后就会有结果！

如果您理解不了的话，可以看我写的Demo！

结语

其实，我猜写这个接口的程序员可能会认为反正数据库数据已经删了，缓存异步更新好像也不影响。但是，从用户层面来讲，如果用户一直不刷新数据，那么可能一直操作的就是删除以后的数据，对于用户来说是很不友好的！

那么，您认为如何避免这种问题呢？这个问题留给大家了！