引入缓存是为了提高查询性能，但在高并发的情况下更新会出现不一致问题
并发引发的一致性问题
假设我们采用「先更新数据库，再更新缓存」的方案，并且两步都可以「成功执行」的前提下，如果存在并发，情况会是怎样的呢？
有线程 A 和线程 B 两个线程，需要更新「同一条」数据，会发生这样的场景：
1.线程 A 更新数据库（X = 1）
2.线程 B 更新数据库（X = 2）
3.线程 B 更新缓存（X = 2）
4.线程 A 更新缓存（X = 1）
最终 X 的值在缓存中是 1，在数据库中是 2，发生不一致。
也就是说，A 虽然先于 B 发生，但 B 操作数据库和缓存的时间，却要比 A 的时间短，执行时序发生「错乱」，最终这条数据结果是不符合预期的。
同样地，采用「先更新缓存，再更新数据库」的方案，也会有类似问题，
除此之外，我们从「缓存利用率」的角度来评估这个方案，也是不太推荐的。
这是因为每次数据发生变更，都「无脑」更新缓存，但是缓存中的数据不一定会被「马上读取」，这就会导致缓存中可能存放了很多不常访问的数据，浪费缓存资源。
而且很多情况下，写到缓存中的值，并不是与数据库中的值一一对应的，很有可能是先查询数据库，再经过一系列「计算」得出一个值，才把这个值才写到缓存中。
由此可见，这种「更新数据库 + 更新缓存」的方案，不仅缓存利用率不高，还会造成机器性能的浪费。
所以此时我们需要考虑另外一种方案：删除缓存。
删除缓存可以保证一致性吗？
删除缓存对应的方案也有 2 种：
先删除缓存，后更新数据库
先更新数据库，后删除缓存
这里我们重点来看「并发」问题。
1) 先删除缓存，后更新数据库
如果有 2 个线程要并发「读写」数据，可能会发生以下场景：
线程 A 要更新 X = 2（原值 X = 1）
线程 A 先删除缓存
线程 B 读缓存，发现不存在，从数据库中读取到旧值（X = 1）
线程 A 将新值写入数据库（X = 2）
线程 B 将旧值写入缓存（X = 1）
最终 X 的值在缓存中是 1（旧值），在数据库中是 2（新值），发生不一致。
可见，先删除缓存，后更新数据库，当发生「读+写」并发时，还是存在数据不一致的情况。
2) 先更新数据库，后删除缓存
依旧是 2 个线程并发「读写」数据：
缓存中 X 不存在（数据库 X = 1）
线程 A 读取数据库，得到旧值（X = 1）
线程 B 更新数据库（X = 2)
线程 B 删除缓存
线程 A 将旧值写入缓存（X = 1）
最终 X 的值在缓存中是 1（旧值），在数据库中是 2（新值），也发生不一致。
这种情况「理论」来说是可能发生的，但实际真的有可能发生吗？
其实概率「很低」，这是因为它必须满足 3 个条件：
缓存刚好已失效
读请求 + 写请求并发
更新数据库 + 删除缓存的时间（步骤 3-4），要比读数据库 + 写缓存时间短（步骤 2 和 5）
仔细想一下，条件 3 发生的概率其实是非常低的。
因为写数据库一般会先「加锁」，所以写数据库，通常是要比读数据库的时间更长的。
这么来看，「先更新数据库 + 再删除缓存」的方案，是可以保证数据一致性的。
所以，我们应该采用这种方案，来操作数据库和缓存。
好，解决了并发问题，我们继续看第二步执行「失败」导致数据不一致的问题。
如何保证两步都执行成功？
前面我们分析到，无论是更新缓存还是删除缓存，只要第二步发生失败，那么就会导致数据库和缓存不一致。
方案是：异步重试
- 更新完数据库后写MQ，放在一个事务里
- 订阅mysql的binlog写MQ
- 消费MQ进行缓存删除，失败重试
至此，想要保证数据库和缓存一致性，推荐采用「先更新数据库，再删除缓存」方案，并配合「消息队列」或「订阅变更日志」的方式来做。
主从库延迟和延迟双删问题
关于「读写分离 + 主从复制延迟」情况下，缓存和数据库一致性的问题。
在「先更新数据库，再删除缓存」方案下，「读写分离 + 主从库延迟」其实也会导致不一致：
线程 A 更新主库 X = 2（原值 X = 1）
线程 A 删除缓存
线程 B 查询缓存，没有命中，查询「从库」得到旧值（从库 X = 1）
从库「同步」完成（主从库 X = 2）
线程 B 将「旧值」写入缓存（X = 1）
最终 X 的值在缓存中是 1（旧值），在主从库中是 2（新值），也发生不一致。
看到了么？这 2 个问题的核心在于：缓存都被回种了「旧值」。
那怎么解决这类问题呢？
业界给出的方案：缓存延迟双删策略。
但问题来了，这个「延迟删除」缓存，延迟时间到底设置要多久呢？
问题1：延迟时间要大于「主从复制」的延迟时间
问题2：延迟时间要大于线程 B 读取数据库 + 写入缓存的时间
但是，这个时间在分布式和高并发场景下，其实是很难评估的。
很多时候，我们都是凭借经验大致估算这个延迟时间，例如延迟 1-5s，只能尽可能地降低不一致的概率。
所以你看，采用这种方案，也只是尽可能保证一致性而已，极端情况下，还是有可能发生不一致。
所以实际使用中，我还是建议你采用「先更新数据库，再删除缓存」的方案，同时，要尽可能地保证「主从复制」不要有太大延迟，降低出问题的概率。
可以做到强一致吗？
看到这里你可能会想，这些方案还是不够完美，我就想让缓存和数据库「强一致」，到底能不能做到呢？
其实很难。
要想做到强一致，最常见的方案是 2PC、3PC、Paxos、Raft 这类一致性协议，但它们的性能往往比较差，而且这些方案也比较复杂，还要考虑各种容错问题。
相反，这时我们换个角度思考一下，我们引入缓存的目的是什么？
没错，性能。
一旦我们决定使用缓存，那必然要面临一致性问题。性能和一致性就像天平的两端，无法做到都满足要求。
而且，就拿我们前面讲到的方案来说，当操作数据库和缓存完成之前，只要有其它请求可以进来，都有可能查到「中间状态」的数据。
所以如果非要追求强一致，那必须要求所有更新操作完成之前期间，不能有「任何请求」进来。
虽然我们可以通过加「分布锁」的方式来实现，但我们要付出的代价，很可能会超过引入缓存带来的性能提升。
所以，既然决定使用缓存，就必须容忍「一致性」问题，我们只能尽可能地去降低问题出现的概率。
同时我们也要知道，缓存都是有「失效时间」的，就算在这期间存在短期不一致，我们依旧有失效时间来兜底，这样也能达到最终一致。
总结
1、想要提高应用的性能，可以引入「缓存」来解决
2、引入缓存后，需要考虑缓存和数据库一致性问题，推荐用「先更新数据库，再删除缓存」的方案
3、在「先更新数据库，再删除缓存」方案下，为了保证两步都成功执行，需配合「消息队列」或「订阅变更日志」的方案来做，本质是通过「重试」的方式保证数据一致性
4、在「先更新数据库，再删除缓存」方案下，「读写分离 + 主从库延迟」也会导致缓存和数据库不一致，缓解此问题的方案是「延迟双删」，凭借经验发送「延迟消息」到队列中，延迟删除缓存，同时也要控制主从库延迟，尽可能降低不一致发生的概率