在缓存使用过程中，通常包含以下三个步骤：
- 查询缓存中是否存在数据。
- 查询数据库数据。
- 将数据写入缓存。
在仅考虑这个过程时，似乎没有问题。然而，当数据发生修改时，我们需要看看可能出现的问题。
修改策略通常有三种：
- 先修改数据库，然后删除缓存。
- 先删除缓存，然后更新数据库。
- 热更新缓存 + 更新数据库。
让我们分别看看这几种场景：
先修改DB 再删除缓存
当两个线程同时进行查询和更新时，存在一个数据更新过程中完成了数据库的修改和缓存的删除的可能性。这样就导致了数据的不一致问题，具体流程如下：
先删除缓存再更新DB
因为没有解决用旧的数据更新缓存的问题，这种方式也存在数据的不一致性的问题。
热更新缓存策略
这种策略思想是优先更新缓存，让缓存达到可用的状态，查询时候直接查询缓存。但是对于多字段修改来说会存在缓存覆盖的问题：
经过我们上面的讨论，我们发现这三种策略都不能解决高并发环境下的缓存一致性的问题，那到底如何解决呢？
延迟双删技术
延迟双删简称是 Cache Aside Pattern，是在删除的基础上再进行一个异步的删除，具体实现方式可以根据具体场景实现，通常采用的策略是MQ消息的方式。具体流程如下：
延迟双删采用了最终一致性解决了缓存一致性的问题。
但是同样带来的缓存丢失的问题，虽然说后续的查询会重新从DB中查询写入缓存，但是如果是查询非常高的场景，会是DB带来大量的查询压力。
延迟双删的改进
为了解决延迟双删带来查询DB的问题，我们可以对其进行修改。如果我们查询对于数据的要求没有那么高，那我们可以把两次删除的策略改成缓存的预热，这样即保证了有缓存，也保证的缓存的最终一致性。
这个场景保证了有数据保护DB服务器，同样也保证了数据最终一致性，但是也同样的带来实现的复杂度。