• Cache Aside（旁路缓存）策略；
• Read/Write Through（读穿 / 写穿）策略；
• Write Back（写回）策略；

实际开发中，Redis 和 MySQL 的更新策略用的是 Cache Aside，另外两种策略应用不了。

Cache Aside

应用程序直接与「数据库、缓存」交互，并负责对缓存的维护

适合读多写少的场景

「先更新数据库 + 再删除缓存」

为了确保数据库和缓存的一致性，最佳方案是**「先更新数据库 + 再删除缓存」，同时缓存数据加上过期时间确保最终一致性。**

因为缓存的写入通常要远远快于数据库的写入

需要确保两个操作都能执行成功，如果删除缓存操作执行失败，还是会导致数据不一致。

如果确保两个操作都能执行成功？

• 重试机制
  • 引入消息队列，将需要删除的缓存值放入消息队列，由消费者来操作数据
    • 如果应用删除缓存失败，可以从消息队列中重新读取数据，然后再次删除缓存，这个就是重试机制。当然，如果重试超过的一定次数，还是没有成功，我们就需要向业务层发送报错信息了。
    • 如果删除缓存成功，就要把数据从消息队列中移除，避免重复操作，否则就继续重试。
• 订阅MySQL binlog，再操作缓存

但是该方案虽然保证了一致性，但每次更新数据时缓存都会被删除，对缓存命中率有影响。

「更新数据库 + 更新缓存」

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

但**「更新数据库 + 更新缓存」**的方案在并发情况下会发生数据不一致，为了确保数据一致性，方法有：