更新数据时，删除缓存失败了怎么办？

当多个请求并发更新同一条数据的时候，可能会出现缓存和数据库中的数据不一致的现。无论是先更新数据库，再更新缓存；还是先更新缓存，再更新数据库，都无法解决。

• 先更新数据库，再删除缓存

• 先删除缓存，再更新数据库

由于缓存的写入通常要远远快于数据库的写入，所以先更新数据库，再删除缓存更优。

难点：更新数据库和删除缓存是两个操作，如果更新数据库后，删除缓存的操作失败或丢失了，缓存中的数据依旧是旧的，要 保证 [先更新数据库，再删除缓存] 再两个操作都能执行成功。

解决方法：

• 消息队列重试机制

• 订阅 MySQL binlog，再操作缓存

消息队列重试机制

将删除缓存要操作的数据加入到消息队列，由消费者操作数据。

• 如果应用删除缓存失败，可以从消息队列中重新读取数据，然后再次删除缓存，这个就是重试机制。当然，如果重试超过的一定次数，还是没有成功，我们就需要向业务层发送报错信息了。

• 如果删除缓存成功，就要把数据从消息队列中移除，避免重复操作，否则就继续重试。

缺点：代码入侵性强，需要改造原本业务的代码

订阅 MySQL binglog

「先更新数据库，再删缓存」的策略的第一步是更新数据库，那么更新数据库成功，就会产生一条变更日志，记录在 binlog 里。

可以通过订阅 binlog 日志，拿到具体要操作的数据，然后再执行缓存删除，阿里巴巴开源的 Canal 中间件就是基于这个实现的。我们可以通过 Canal+ 消息队列的方案来保证数据缓存的一致性。

将binlog日志采集发送到MQ队列里面，然后编写一个简单的缓存删除消息者订阅binlog日志，根据更新log删除缓存，并且通过ACK机制确认处理这条更新log，保证数据缓存一致性

有一个很关键的点，必须是删除缓存成功，再回 ack 机制给消息队列，否则可能会造成消息丢失的问题

补充

「先更新数据库，再删除缓存」的方案虽然保证了数据库与缓存的数据一致性，但是每次更新数据的时候，缓存的数据都会被删除，这样会对缓存的命中率带来影响。

如果我们的业务对缓存命中率有很高的要求，我们可以采用「更新数据库 + 更新缓存」的方案，因为更新缓存并不会出现缓存未命中的情况。

但是当多个请求并发执行时，会出现数据不一致问题，因为更新数据库和更新缓存这两个操作是独立的，要解决这个问题，一般有两种做法：

• 在更新缓存前先加个分布式锁，保证同一时间只运行一个请求更新缓存，就会不会产生并发问题了，当然引入了锁后，对于写入的性能就会带来影响。

• 在更新完缓存时，给缓存加上较短的过期时间，这样即使出现缓存不一致的情况，缓存的数据也会很快过期，对业务还是能接受的。