而这时候大部分的流量实际上都是读请求，而且大部分数据也是没有那么多变化的，如热门商品信息、微博的内容等常见数据就是如此。此时，缓存就是我们应对此类场景的利器。

缓存的意义

所谓缓存，实际上就是用空间换时间，准确地说是用更高速的空间来换时间，从而整体上提升读的性能。

何为更高速的空间呢？

更快的存储介质。通常情况下，如果说数据库的速度慢，就得用更快的存储组件去替代它，目前最常见的就是Redis（内存存储）。Redis 单实例的读 QPS 可以高达 10w/s，90% 的场景下只需要正确使用 Redis 就能应对。

就近使用本地内存。就像 CPU 也有高速缓存一样，缓存也可以分为一级缓存、二级缓存。即便 Redis 本身性能已经足够高了，但访问一次 Redis 毕竟也需要一次网络 IO，而使用本地内存无疑有更快的速度。不过单机的内存是十分有限的，所以这种一级缓存只能存储非常少量的数据，通常是最热点的那些 key 对应的数据。这就相当于额外消耗宝贵的服务内存去换取高速的读取性能。

引入缓存后的一致性挑战

实际上，最权威最全的数据还是在 MySQL 里的。而万一 Redis数据没有得到及时的更新（例如数据库更新了没更新到Redis），就出现了数据不一致。

大部分情况下，只要使用了缓存，就必然会有不一致的情况出现，只是说这个不一致的时间窗口是否能做到足够的小。有些不合理的设计可能会导致数据持续不一致，这是我们需要改善设计去避免的。

这里的一致性实际上对于本地缓存也是同理的，例如数据库更新后没有及时更新本地缓存，也是有一致性问题的，下文统一以Redis缓存作为引子讲述，实际上处理本地缓存原理基本一致。

（一）缓存不一致性无法客观地完全消灭

理想情况下，我们需要在数据库更新完后把对应的最新数据同步到缓存中，以便在读请求的时候能读到新的数据而不是旧的数据（脏数据）。但是很可惜，由于数据库和 Redis 之间是没有事务保证的，所以我们无法确保写入数据库成功后，写入 Redis 也是一定成功的；即便 Redis 写入能成功，在数据库写入成功后到 Redis 写入成功前的这段时间里，Redis 数据也肯定是和 MySQL 不一致的。如下两图所示：

无法事务保持一致

所以说这个时间窗口是没办法完全消灭的，除非我们付出极大的代价，使用分布式事务等各种手段去维持强一致，但是这样会使得系统的整体性能大幅度下降，甚至比不用缓存还慢，这样不就与我们使用缓存的目标背道而驰了吗？

也就是说优先查询缓存，查询不到才查询数据库。如果这时候数据库查到数据了，就将缓存的数据进行更新。这是我们常说的cache aside的策略，也是最常用的策略。

这样的逻辑是正确的，而一致性的问题一般不来源于此，而是出现在处理写请求的时候。所以我们简化成最简单的写请求的逻辑，此时你可能会面临多个选择，究竟是直接更新缓存，还是失效缓存？而无论是更新缓存还是失效缓存，都可以选择在更新数据库之前，还是之后操作。

这样就演变出 4 个策略：更新数据库后更新缓存、更新数据库前更新缓存、更新数据库后删除缓存、更新数据库前删除缓存。下面我们来分别讲述。

（一）更新数据库后更新缓存的不一致问题

一种常见的操作是，设置一个过期时间，让写请求以数据库为准，过期后，读请求同步数据库中的最新数据给缓存。那么在加入了过期时间后，是否就不会有问题了呢？并不是这样。

大家设想一下这样的场景。

假如这里有一个计数器，把数据库自减 1，原始数据库数据是 100，同时有两个写请求申请计数减一，假设线程 A 先减数据库成功，线程 B 后减数据库成功。那么这时候数据库的值是 98，缓存里正确的值应该也要是 98。

但是特殊场景下，你可能会遇到这样的情况：

线程 A 和线程 B 同时更新这个数据

更新数据库的顺序是先 A 后 B

updateMySQL();updateRedis(key, data);

就可能出现：数据库的值是 100->99->98，但是缓存的数据却是 100->98->99，也就是数据库与缓存的不一致。而且这个不一致只能等到下一次数据库更新或者缓存失效才可能修复。

当然，如果更新Redis本身是失败的话，两边的值固然也是不一致的，这个前文也阐述过，几乎无法根除。

那你可能会想，这是否表示，我应该先让缓存更新，之后再去更新数据库呢？类似这样：

updateRedis(key, data);//先更新缓存updateMySQL();//再更新数据库

这样操作产生的问题更是显而易见的，因为我们无法保证数据库的更新成功，万一数据库更新失败了，你缓存的数据就不只是脏数据，而是错误数据了。

• 线程 A 和线程 B 同时更新同这个数据

  
  

• 更新缓存的顺序是先 A 后 B

  
  

• 更新数据库的顺序是先 B 后 A

举个例子。线程 A 希望把计数器置为 0，线程 B 希望置为 1。而按照以上场景，缓存确实被设置为 1，但数据库却被设置为 0。

所以通常情况下，更新缓存再更新数据库是我们应该避免使用的一种手段。

（三）更新数据库前删除缓存的问题

那如果采取删除缓存的策略呢？也就是说我们在更新数据库的时候失效对应的缓存，让缓存在下次触发读请求时进行更新，是否会更好呢？同样地，针对在更新数据库前和数据库后这两个删除时机，我们来比较下其差异。

最直观的做法，我们可能会先让缓存失效，然后去更新数据库，代码逻辑如下：

deleteRedis(key);//先删除缓存让缓存失效updateMySQL();//再更新数据库

这样的逻辑看似没有问题，毕竟删除缓存后即便数据库更新失败了，也只是缓存上没有数据而已。然后并发两个写请求过来，无论怎么样的执行顺序，缓存最后的值也都是会被删除的，也就是说在并发写写的请求下这样的处理是没问题的。

然而，这种处理在读写并发的场景下却存在着隐患。

还是刚刚更新计数的例子。例如现在缓存的数据是 100，数据库也是 100，这时候需要对此计数减 1，减成功后，数据库应该是 99。如果这之后触发读请求，缓存如果有效的话，里面应该也要被更新为 99 才是正确的。

那么思考下这样的请求情况：

线程 A 更新这个数据的同时，线程 B 读取这个数据

线程 A 成功删除了缓存里的老数据，这时候线程 B 查询数据发现缓存失效

线程 A 更新数据库成功

可以看到，在读写并发的场景下，一样会有不一致的问题。

针对这种场景，有个做法是所谓的“延迟双删策略”，就是说，既然可能因为读请求把一个旧的值又写回去，那么我在写请求处理完之后，等到差不多的时间延迟再重新删除这个缓存值。

这种解决思路的关键在于对 N 的时间的判断，如果 N 时间太短，线程 A 第二次删除缓存的时间依旧早于线程 B 把脏数据写回缓存的时间，那么相当于做了无用功。而 N 如果设置得太长，那么在触发双删之前，新请求看到的都是脏数据。

（四）更新数据库后删除缓存

那如果我们把更新数据库放在删除缓存之前呢，问题是否解决？我们继续从读写并发的场景看下去，有没有类似的问题。

可以看到，大体上，采取先更新数据库再删除缓存的策略是没有问题的，仅在更新数据库成功到缓存删除之间的时间差内——[T2,T3)的窗口 ，可能会被别的线程读取到老值。

而在开篇的时候我们说过，缓存不一致性的问题无法在客观上完全消灭，因为我们无法保证数据库和缓存的操作是一个事务里的，而我们能做到的只是尽量缩短不一致的时间窗口。

在更新数据库后删除缓存这个场景下，不一致窗口仅仅是 T2 到 T3 的时间，内网状态下通常不过 1ms，在大部分业务场景下我们都可以忽略不计。因为大部分情况下一个用户的请求很难能再1ms内快速发起第二次。

但是真实场景下，还是会有一个情况存在不一致的可能性，这个场景是读线程发现缓存不存在，于是读写并发时，读线程回写进去老值。并发情况如下：

总的来说，这个不一致场景出现条件非常严格，因为并发量很大时，缓存不太可能不存在；如果并发很大，而缓存真的不存在，那么很可能是这时的写场景很多，因为写场景会删除缓存。

所以待会我们会提到，写场景很多时候实际上并不适合采取删除策略。

（五）总结四种更新策略

终上所述，我们对比了四个更新缓存的手段，做一个总结对比，其中应对方案也提供参考，具体不做展开，如下表：

从一致性的角度来看，采取更新数据库后删除缓存值，是更为适合的策略。因为出现不一致的场景的条件更为苛刻，概率相比其他方案更低。

那么是否更新缓存这个策略就一无是处呢？不是的！

删除缓存值意味着对应的 key 会失效，那么这时候读请求都会打到数据库。如果这个数据的写操作非常频繁，就会导致缓存的作用变得非常小。而如果这时候某些 Key 还是非常大的热 key，就可能因为扛不住数据量而导致系统不可用。

如下图所示：

删除策略频繁的缓存失效导致读请求无法利用缓存

所以做个简单总结，足以适应绝大部分的互联网开发场景的决策：

针对大部分读多写少场景，建议选择更新数据库后删除缓存的策略。

针对读写相当或者写多读少的场景，建议选择更新数据库后更新缓存的策略。

最终一致性如何保证？

缓存设置过期时间

如何减少缓存删除/更新的失败？

万一删除缓存这一步因为服务重启没有执行，或者 Redis 临时不可用导致删除缓存失败了，就会有一个较长的时间（缓存的剩余过期时间）是数据不一致的。

那我们有没有什么手段来减少这种不一致的情况出现呢？这时候借助一个可靠的消息中间件就是一个不错的选择。

因为消息中间件有 ATLEAST-ONCE 的机制，如下图所示。

我们把删除 Redis 的请求以消费 MQ 消息的手段去失效对应的 Key 值，如果 Redis 真的存在异常导致无法删除成功，我们依旧可以依靠 MQ 的重试机制来让最终 Redis 对应的 Key 失效。

而你们或许会问，极端场景下，是否存在更新数据库后 MQ 消息没发送成功，或者没机会发送出去机器就重启的情况？

如何处理复杂的多缓存场景？

有些时候，真实的缓存场景并不是数据库中的一个记录对应一个 Key 这么简单，有可能一个数据库记录的更新会牵扯到多个 Key 的更新。还有另外一个场景是，更新不同的数据库的记录时可能需要更新同一个 Key 值，这常见于一些 App 首页数据的缓存。

我们以一个数据库记录对应多个 Key 的场景来举例。

假如系统设计上我们缓存了一个粉丝的主页信息、主播打赏榜 TOP10 的粉丝、单日 TOP 100 的粉丝等多个信息。如果这个粉丝注销了，或者这个粉丝触发了打赏的行为，上面多个 Key 可能都需要更新。只是一个打赏的记录，你可能就要做：

updateMySQL();//更新数据库一条记录deleteRedisKey1();//失效主页信息的缓存updateRedisKey2();//更新打赏榜TOP10deleteRedisKey3();//更新单日打赏榜TOP100

这就涉及多个 Redis 的操作，每一步都可能失败，影响到后面的更新。甚至从系统设计上，更新数据库可能是单独的一个服务，而这几个不同的 Key 的缓存维护却在不同的 3 个微服务中，这就大大增加了系统的复杂度和提高了缓存操作失败的可能性。最可怕的是，操作更新记录的地方很大概率不只在一个业务逻辑中，而是散发在系统各个零散的位置。

针对这个场景，解决方案和上文提到的保证最终一致性的操作一样，就是把更新缓存的操作以 MQ 消息的方式发送出去，由不同的系统或者专门的一个系统进行订阅，而做聚合的操作。如下图：

专门更新缓存的服务订阅MQ消息维护所有相关Key的缓存操作

通过订阅MySQL binlog的方式处理缓存

上面讲到的 MQ 处理方式需要业务代码里面显式地发送 MQ 消息。还有一种优雅的方式便是订阅 MySQL 的 binlog，监听数据的真实变化情况以处理相关的缓存。

例如刚刚提到的例子中，如果粉丝又触发打赏了，这时候我们利用 binlog 表监听是能及时发现的，发现后就能集中处理了，而且无论是在什么系统什么位置去更新数据，都能做到集中处理。

目前业界类似的产品有 Canal，具体的操作图如下：

利用Canel订阅数据库binlog变更从而发出MQ消息，让一个专门消费者服务维护所有相关Key的缓存操作

到这里，针对大型系统缓存设计如何保证最终一致性，我们已经从策略、场景、操作方案等角度进行了细致的讲述，希望能对你起到帮助。

点击下方空白 ▼ 查看明日开发者黄历

注：本文基于本人博客https://jaskey.github.io/blog/2022/04/14/cache-consistency/

作者个人邮箱jaskeylin@apache.org，微信：JaskeyLam