缓存失败了怎么办？

删缓存失败怎么办？

如果缓存删除失败了，也会导致缓存和数据库的数据不一致。

所以为了解决这个方案，我们加入一个重试机制。

在接口中如果更新了数据库成功了，但更新缓存失败了，可以立刻重试3次。如果其中有任何一次成功，则直接返回成功。如果3次都失败了，则写入数据库，准备后续再处理。

当然，如果你在接口中直接同步重试，该接口并发量比较高的时候，可能有点影响接口性能，这个我们不怕，可以改为异步。

异步重试方式有很多种：

1.每次都单独起一个线程，该线程专门做重试的工作。但如果在高并发的场景下，可能会创建太多的线程，导致系统OOM问题，不太建议使用。

2.将重试的任务交给线程池处理，但如果服务器重启，部分数据可能会丢失。

3.将重试数据写表，然后使用elastic-job等定时任务进行重试。

4.将重试的请求写入mq等消息中间件中，在mq的consumer中处理。

5.订阅mysql的binlog，在订阅者中，如果发现了更新数据请求，则删除相应的缓存。

定时任务

我们创建一个重试表，表中有个字段记录重试次数，初始值为0，同时设置一个最大的重试次数，用一个定时任务异步的去读取重试表中的数据，然后去执行删除缓存操作，每删除一次，重试次数加1，如果其中有任意一次成功了，则返回成功。如果重试了5次，还是失败，则我们需要在重试表中记录一个失败的状态，等待后续进一步处理。

在高并发场景中，定时任务推荐使用elastic-job。相对于xxl-job等定时任务，它可以分片处理，提升处理速度。同时每片的间隔可以设置成：1,2,3,5,7秒等。

使用定时任务重试的话，有个缺点就是实时性没那么高，对于实时性要求特别高的业务场景，该方案不太适用。但是对于一般场景，还是可以用一用的。

但它有一个很大的优点，即数据是落库的，不会丢数据。

MQ

在高并发的业务场景中，mq（消息队列）是必不可少的技术之一。它不仅可以异步解耦，还能削峰填谷。对保证系统的稳定性是非常有意义的。

mq的生产者，生产了消息之后，通过指定的topic发送到mq服务器。然后mq的消费者，订阅该topic的消息，读取消息数据之后，做业务逻辑处理。

使用mq重试的具体方案如下：

当用户操作写完数据库，但删除缓存失败了，产生一条mq消息，发送给mq服务器。

mq消费者读取mq消息，重试5次删除缓存。如果其中有任意一次成功了，则返回成功。如果重试了5次，还是失败，则写入死信队列中。

当然在该方案中，删除缓存可以完全走异步。即用户的写操作，在写完数据库之后，不用立刻删除一次缓存。而直接发送mq消息，到mq服务器，然后有mq消费者全权负责删除缓存的任务。

因为mq的实时性还是比较高的，因此改良后的方案也是一种不错的选择。

binlog

前面两种删除的重试方案 都有一定的侵入性：

在使用定时任务的方案中，需要在业务代码中增加额外逻辑，如果删除缓存失败，需要将数据写入重试表。

使用mq的方案中，如果删除缓存失败了，需要在业务代码中发送mq消息到mq服务器。

其实，还有一种更优雅的实现，即监听binlog，比如使用：canal等中间件。

具体方案如下：

在业务接口中写数据库之后，就不管了，直接返回成功。

mysql服务器会自动把变更的数据写入binlog中。

binlog订阅者获取变更的数据，然后删除缓存。

这套方案中业务接口确实简化了一些流程，只用关心数据库操作即可，而在binlog订阅者中做缓存删除工作。

但是呢，这种方案还会出现删除失败的情况，因为基于binlog实现的删除只会删除一次，所以我们最终还是需要依赖于基于定时任务或者mq的重试机制。

在binlog订阅者中如果删除缓存失败，则发送一条mq消息到mq服务器，在mq消费者中自动重试5次。如果有任意一次成功，则直接返回成功。如果重试5次后还是失败，则该消息自动被放入死信队列，后面可能需要人工介入。