引入缓存提高性能
如果你的业务处于起步阶段，流量非常小，那无论是读请求还是写请求，直接操作数据库即可，这时，你的架构模型是这样的：
但是随着业务的增长，你的项目也来越大，这时如果每次都从数据库中读取数据，那肯定会有性能问题。
这个阶段通通常通过引入缓存来提高读性能，架构就变成了这样:
当下优秀的缓存中间件，当属 Reids 莫属，它不仅性能非常高，还提供了很多非常友好的数据类型，可以很好的满足我们的业务场景。
但当引入了缓存之后，你就会面临一个问题：之前的数据只存在数据库中，现在要放到缓存中一份，如何保证两份数据的一致性呢？？？
缓存利用率和一致性问题
缓存利用率
先看第一个问题，如何提高缓存利用率？
想要缓存利用率最大化，我们最容易想到的方案是，缓存中只保留最近访问的热数据。我们可以这样做：
- 写请求依旧只写数据库
- 读请求先读缓存，如果缓存不存在，则从数据库读取，并重建缓存
- 同时，写入缓存中的数据，都设置实效时间
这样一来，缓存中不经常访问的数据，随着时间的推移，都会逐渐过期淘汰掉，最终缓存中保留的，都是经常被访问的热数据，缓存利用率得以最大化。
一致性问题
要想保证缓存和数据库实时一致，需要当数据发生更新时，我们不仅要操作数据库，还要一并操作缓存。
但数据库和缓存都更新，又存在先后问题，那对应的方案就有 2 个：
- 先更新缓存，后更新数据库
- 先更新数据库，后更新缓存
哪个方案更好呢？
在不考虑并发问题，正常情况下，无论谁先谁后，都可以让两者保持一致，但现在我们需要重点考虑异常情况。
因为操作分两步，那么就很有可能存在第一步成功，第二步失败的情况。
这两种情况我们一个个来进行分析。
先更新缓存，后更新数据库
如果缓存更新成功了，但数据库更新失败，此时缓存中的是最新值，但数据库中是旧值。
虽然此时读请求可以命中缓存，拿到正确的值，但是，一旦缓存过期失效，就会从数据库中读取到旧值，重建缓存也是旧值。
这时用户就会发现自己之前修改的数据又变回去了，对业务造成影响。
先更新数据库，后更新缓存
如果数据库更新成功了，但缓存更新失败，那么此时数据库中是最新值，缓存中时旧值。
之后的读请求读到的都是旧值，只有当缓存过期失效后，才能从数据库中得到正确的值。
这时用户会发现，自己刚刚修改了数据，但却看不到变更，一段时间过后，数据才变更过来，对业务也会有影响。
可见，谁先谁后，但凡后者发生异常，就会对业务造成影响，那怎么解决这个问题呢？？？(别急，我们后面再详细分析对于对解决方案)
我们继续分析，除了操作失败问题，还有什么场景会影响数据一致性呢？？
这里我们还需要重点关注：并发问题。
并发问题
假设我们采用先更新数据库，再更新缓存的方案，并且两步都可以成功执行的前提下，如果存在并发，情况会是怎样的呢？？
有线程 A 和线程 B，需要更新同一条数据，会发生这样的场景：
- 线程 A 更新数据库（X = 1）
- 线程 B 更新数据库（X = 2）
- 线程 B 更新缓存（X = 2）
- 线程 A 更新缓存 (X = 1)
最终 X 的值在数据库中时 2，但在缓存中是 1，发生不一致。
也就是说，A 虽然先于 B 发生，但 B 操作数据库和缓存的时间，却比 A 对时间短，执行时序发生错乱，最终这条数据结构是不符合预期的。
同样的，这里采用 先更新缓存，后更新数据库的方案，也会有类似的问题，这里不再进行赘述。
那怎么解决这个问题呢？这里通常的解决方案是，加 分布式锁。
两个线程要修改同一条数据，每个线程在改之前，先去申请分布式锁，拿到锁 的线程才允许更新数据库和缓存，拿不到锁的线程，返回失败，等待下次重试。
这么做的目的，就是为了只允许一个线程去操作数据和缓存，避免并发问题。
除此之外，我们从缓存利用率的角度来评估这个方案，也是不太推荐的。
这是因为每次数据发生变更，都无脑更新缓存，但是缓存中的数据并不一定会被马上读取，这就会导致缓存中可能存放了很多不常访问的数据，浪费缓存资源。
而且很多情况下，写到缓存中的值，并不是与数据库中的值一一对应，很有可能是先查询数据库，再经过一系列计算得出一个值，才把这个值写到缓存中。
由此可见，这种更新数据库 + 更新缓存 的方案，不仅缓存利用率不高，还会造成机器性能的浪费。
所以此时我们要考虑另外一种方案：删除缓存。
删除缓存可以保证一致性吗？
一致性问题
删除缓存对应也有 2 种方案：
- 先删除缓存，后更新数据库
- 先更新数据库，后删除缓存
同样的，我们来分析第二步失败的情况。
先删除缓存，后更新数据库，第二步操作失败，数据库没有更新成功，那下次读缓存发现不存在，则从数据库中读取，并重建缓存，此时数据库和缓存依旧保持一致。
但如果是先更新数据库，后删除缓存，第二步操作失败，数据库中是最新值，缓存中是旧值，发生不一致。所以，这个方案依旧存在问题。
总之，和前面提到的问题类似，第二步失败依旧有不一致的风险。
好，我们再来看并发问题，这个问题是我们要关注的重点。
先删除缓存，后更新数据库
如果有 2 个线程要并发读写数据，可能会发生以下场景：
假定：线程 A 要更新 X = 2 (原值 X = 1)
- 线程 A 先删除缓存
- 线程 B 读缓存，发现不存在，从数据库读取到旧值(X = 1)
- 线程 A 将新值写入数据库（X = 2）
- 线程 B 将旧值写入缓存（X = 1）
最终 X 的值在缓存中时 1（旧值）， 但在数据库中是 2 (新值)，发生不一致。
可见，先删除缓存，后更新数据库，当发生读写并发时，还是存在数据不一致的情况。
先更新数据库，后删除缓存
依旧是 2 个线程并发 读写数据：
假定：缓存中 X 不存在（数据库 X = 1）
- 线程 A 读取数据库，得到旧值（X = 1）
- 线程 B 更新数据库（X = 2）
- 线程 B 删除缓存
- 线程 A 将旧值写入缓存（X = 1）
最终 X 在缓存中是 1(旧值)，但在数据库中是 2(新值)，也发生不一致。
这种情况理论上来说是可能发生的，但实际真的有可能发生吗？
其实概率很低。这是因为它必须满足 3 个条件：
- 缓存刚好已失效
- 读写请求并发
- time(更新数据库 + 删除缓存)[步骤3-4] < time(读取数据库 + 写缓存)[步骤2和5]
仔细想一下，条件 3 发生的概率其实是非常低的。
因为写数据库一般会先加锁，所以写数据库，通常要比读数据库的时间更长。
这么来看，先更新数据库，后删除缓存的方案，是可以保证数据一致性的。
所以，我们应该采用这种方案，来操作数据库和缓存。
好，解决了并发问题，我们继续来看前面遗留的，第二步执行失败导致不一致的问题。
如何保证两步都执行成功？
前面我们分析到，无论是更新缓存还是删除缓存，只要第二步发生失败，那么就会导致数据库和缓存不一致。
保证第二步成功执行，就是解决问题的关键。
想一下，程序在执行过程中发生异常，最简单的解决办法是什么？
是 重试！！！
是的，其实这里我们也可以这样做。
无论是先操作缓存，还是先操作数据库，但凡后者执行失败了，我们就可以发起重试，尽可能地去做补偿。
那这是不是意味着，只要执行失败，我们无脑重试就可以了呢？
答案是否定的。现实情况往往没有想的这么简单，失败后立即重试的问题在于：
- 立即重试很大概率还会失败
- 重试次数设置多少才合理
- 重试会一直占用这个线程资源，无法服务其它客户端请求
看到了吧，虽然我们想通过重试的方式解决问题，但这种同步重试的方案很不严谨。
那更好的方案应该怎么做呢？
答案是： 异步重试。什么是异步重试呢？
其实就是把重试请求写到消息队列中，然后由专门的消费者来重试，直到成功。
或者更直接的做法，为了避免第二步执行失败，我们可以把操作缓存这一步，直接放到消息队列中，由消费者来操作缓存。
到这里你可能会问，写消息队列也有可能会失败啊？而且，引入消息队列，这又增加了更多维护成本，这样做值得吗？
这个问题很好，但我们思考这样一个问题：如果在执行失败的线程中一直重试，还没等执行成功，此时如果项目重启了，那这次重试请求也就丢失了，那这条数据就一直不一致了(如果一直不过期的话)。
所以，这里我们必须把重试消息或者第二步操作放到另一个服务中，这个服务用消息队列最为合适。这是因为消息队列的特性，正好符合我们的需求：
- 消息队列保证可靠性：写到队列中的消息，成功消费之前不会丢失（重启项目也不担心）
- 消息队列保证消息成功投递：下游从队列拉去消息，成功消费之后才会删除消息，否则还会继续投递消息给消费着（符合我们重试的需求）
至于写队列失败和消息队列的维护成本问题：
- 写队列失败：操作缓存和写消息队列，同时失败的概率其实是很小的
- 维护成本：我们项目中一般都会用到消息队列，维护成本并没有增加多少
所以，引入消息队列来解决这个问题，是比较合适的，这时架构就变成了这样：
那如果你确实不想在应用程序中去写消息队列，是否有更简单的方案，同时又可以保证一致性呢？
方案还是有的，这就是近几年比较流行的解决方案：订阅数据库变更日志，再操作缓存。
具体来讲，我们的业务应用在修改数据时，只需修改数据库，无需操作缓存。
那什么时候操作缓存呢？这就和数据库的变更日志有关了。
拿 MySQL 举例，当一条数据发生修改时，MySQL 就会产生一条变更日志(Binlog), 我们可以订阅这个日志，拿到具体操作的数据，任何再根据这条数据，去删除对应的缓存。
延迟双删问题和主从延迟问题
到这里，还有 2 个问题，是我们没有重点分析过的。
第一个问题，还记得前面讲到的先删除缓存，再更新数据库导致不一致的场景吗？
这里我再把例子拿过来复习一下：
假定：线程 A 要更新 X = 2 (原值 X = 1)
- 线程 A 先删除缓存
- 线程 B 读缓存，发现不存在，从数据库读取到旧值(X = 1)
- 线程 A 将新值写入数据库（X = 2）
- 线程 B 将旧值写入缓存（X = 1）
最终 X 的值在缓存中时 1（旧值）， 但在数据库中是 2 (新值)，发生不一致。
第二个问题：是关于读写分离 + 主从延迟 情况下，缓存和数据库一致性问题。
如果使用先更新数据库，后删除缓存的方案，其实也发生不一致：
- 线程 A 更新 X = 2 (原值 X = 1)
- 线程 A 删除缓存
- 线程 B 查询缓存，未命中，查询从库得到旧值（从库 X = 1）
- 从库同步完成（主从库 X = 2）
- 线程 B 将旧值写入缓存（X = 1）
最终 X 的值在缓存中时 1（旧值）， 但在数据库中是 2 (新值)，也发生不一致。
看到了吗？这 2 个问题的核心在于：缓存都被回种了旧值。
那么怎么解决这类问题呢？
最有效的办法就是：把缓存删掉。
但是不能立即删，而是需要延迟删，这就是业界给出的方案：缓存延迟双删策略。
解决第一个问题：线程 A 删除缓存、更新完数据库之后，先休眠一会，再删除一次缓存。
解决第二个问题：线程 A 可以生成一条延迟消息，写到消息队列中，消费者延迟删除缓存。
这两个方案的目的，都是为了把缓存清掉，这样一来，下次就可以从数据库中读取到最新值，写入缓存。
但问题来了，这个延迟删除缓存，延迟时间到底要设置多久呢？
问题1: 延迟时间要大于主从复制的延迟时间
问题2: 延迟时间要大于线程 B 读取数据库 + 写入缓存的时间
但是，这个时间在分布式和高并发场景下，其实是很难评估的。这也是延迟双删策略被人诟病的一个原因。
很多时候。我们都是凭借经验大致估算这个延迟时间，例如延迟 1-5 秒，只能尽可能地降低不一致的概率。
所以你看，采用这种方案，也只是尽可能保证一致性而已，极端情况下，还是有可能发生不一致。
所以在实际应用中，我还是建议你采用先更新数据库，再删除缓存的方案，同时，要尽可能地保证主从复制不要有太大的延迟，降低出问题的概率。
可以做到强一致吗？
看到这里，你可能会想，这些方案还是不够完美，我就想让缓存和数据库强一致，到底能不能做到呢？
其实很难。
要想做到这一点，最常见的方案是 2PC、3PC、Paxos、Raft 这种一致性协议，但它们的性能往往比较差，而且这些方案也比较复杂，还要考虑各种容错问题。
相反，这时我们换个角度思考一下，我们引入缓存的目的是什么？？
没错，是性能。
一旦我们决定使用缓存，那必然要面临一致性问题。性能和一致性就像天平⚖️的两端，无法做到都满足要求。
而且，就拿我们前面讲到的方案来说，当操作数据库和缓存完成之前，只要有其它请求进来，都有肯能查到中间状态的数据。
如果非要追求强一致性，那必须要求所有更新操作完成之前，不能有任何请求进来。
虽然我们可以通过加分布式锁的方式来实现，但我们也要付出相应的代价，甚至很可能会超过引入缓存带来的性能提升。
所以，既然决定使用缓存，就必须容忍一致性问题，我们只能尽可能去降低问题发生的概率。
同时我们也要知道，缓存都是有失效时间的，就算在这期间存在短期不一致，我们依旧有失效时间来兜底，这样也能达到最终一致性。
总结
好了，下面总结一下这篇文章的重点：
- 要想提高应用的性能，可以引入缓存来解决
- 引入缓存后，需要考虑缓存和数据库一致性问题，可选的方案有
更新数据库 + 更新缓存或者更新缓存 + 更新数据库 - 更新数据库 + 更新缓存 方案，在并发场景下无法保证缓存和数据的一致性，解决方案是加分布式锁，但这种方案存在缓存资源浪费和机器性能浪费的情况
- 采用先删除缓存，再更新数据库的方案，在并发场景下依旧会发生不一致的情况，解决方案是延迟双删，但这个延迟时间很难评估
- 采用先更新数据库，再删除缓存的方案，为了保证两步都成功，需要配合消息队列或订阅变更日志的方案来做，本质是通过重试的方式来保证数据的最终一致性
- 采用先更新数据库，再删除缓存的方案，读写分离+主从延迟也会导致缓存和数据库不一致，缓解此问题的方案是延迟双删，凭借经验发送延迟消息到队列中，延迟删除缓存，同时也要控制主从延迟，尽可能降低不一致发生的概率。
后记
本来以为是老生常谈的话题，但是写下来的过程中，还是发现有很多之前没有考虑到的细节。
这里也分享 4 点心得：
- 性能和一致性不能同时满足，为了性能考虑，一般会采用最终一致性的方案。
- 掌握缓存和数据库一致性问题，核心问题有 3 点：缓存利用率、并发、缓存 + 数据库一起成功问题
- 失败场景下要保证一致性，常见手段就是重试，同步重试会影响吞吐量，所以通常采用异步重试的方案
- 订阅并更日志的思想，本质是把权威数据源(MySQL)当作 leader，其它异质系统(Redis)成为它的 follower 副本，通过同步变更日志的方式，保证 leader 和 follower 的一致。
很多一致性问题，都会这些方案来解决，希望这些心得能对你有所启发。
实际场景为了成本考虑，也可以不用实现的这么复杂，但你需要知道哪块没做到，会有哪些问题，并且业务能容忍这些问题带来的影响，如果不能容忍，本文的思路你可以借鉴一下。总之，可以根据自己的业务场景选择适合自己的方案。
参考：