导语|缓存合理运用确提高了体系的吞吐量和稳定性，然而这是有价值的。这个价值就是缓存和数据库的共同性带来了应战，本文将针对最常见的cache-aside战略下怎么保护缓存共同性彻底讲透。

可是客观上，咱们的事务规划很或许要求着更高的 QPS，有些事务的规划自身就十分大，也有些事务会遇到一些流量顶峰，比如电商会遇到大促的状况。

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

缓存的意义

所谓缓存，实际上就是用空间换时刻，精确地说是用更高速的空间来换时刻，然后整体上提高读的功能。

何为更高速的空间呢？

更快的存储介质。通常状况下，假设说数据库的速度慢，就得用更快的存储组件去代替它，现在最常见的就是Redis（内存存储）。Redis 单实例的读 QPS 能够高达 10w/s，90% 的场景下只需求正确运用 Redis 就能应对。

就近运用本地内存。就像 CPU 也有高速缓存一样，缓存也能够分为一级缓存、二级缓存。即使 Redis 自身功能现已满足高了，但拜访一次 Redis 究竟也需求一次网络 IO，而运用本地内存无疑有更快的速度。不过单机的内存是十分有限的，所以这种一级缓存只能存储十分少数的数据，通常是最热门的那些 key 对应的数据。这就相当于额外耗费名贵的服务内存去交换高速的读取功能。

引进缓存后的共同性应战

用空间换时刻，意味着数据一起存在于多个空间。最常见的场景就是数据一起存在于 Redis 与 MySQL 上（为了问题的普适性，后边举例中若没有特别阐明，缓存均指 Redis 缓存）。

实际上，最权威最全的数据仍是在 MySQL 里的。而假设 Redis数据没有得到及时的更新（例如数据库更新了没更新到Redis），就呈现了数据不共同。

大部分状况下，只需运用了缓存，就必定会有不共同的状况呈现，仅仅说这个不共同的时刻窗口是否能做到满足的小。有些不合理的规划或许会导致数据持续不共同，这是咱们需求改善规划去防止的。

这儿的共同性实际上关于本地缓存也是同理的，例如数据库更新后没有及时更新本地缓存，也是有共同性问题的，下文共同以Redis缓存作为引子叙述，实际上处理本地缓存原理根本共同。

（一）缓存不共同性无法客观地彻底消除

为什么咱们简直没办法做到缓存和数据库之间的强共同呢？

抱负状况下，咱们需求在数据库更新完后把对应的最新数据同步到缓存中，以便在读恳求的时分能读到新的数据而不是旧的数据（脏数据）。可是很可惜，由于数据库和 Redis 之间是没有事务确保的，所以咱们无法确保写入数据库成功后，写入 Redis 也是必定成功的；即使 Redis 写入能成功，在数据库写入成功后到 Redis 写入成功前的这段时刻里，Redis 数据也肯定是和 MySQL 不共同的。如下两图所示：

无法事务保持共同

所以说这个时刻窗口是没办法彻底消除的，除非咱们支付极大的价值，运用分布式事务等各种手法去维持强共同，可是这样会使得体系的整体功能大幅度下降，乃至比不用缓存还慢，这样不就与咱们运用缓存的目标各走各路了吗？

不过虽然无法做到强共同，可是咱们能做到的是缓存与数据库到达终究共同，并且不共同的时刻窗口咱们能做到尽或许短，依照经验来说，假设能将时刻优化到 1ms 之内，这个共同性问题带来的影响咱们就能够忽略不计。

更新缓存的手法

通常状况下，咱们在处理查询恳求的时分，运用缓存的逻辑如下：

data = queryDataRedis(key);
if (data ==null) {
 data = queryDataMySQL(key); //缓存查询不到，从MySQL做查询
 if (data!=null) {
 updateRedis(key, data);//查询完数据后更新MySQL最新数据到Redis
 }
}

也就是说优先查询缓存，查询不到才查询数据库。假设这时分数据库查到数据了，就将缓存的数据进行更新。这是咱们常说的cache aside的战略，也是最常用的战略。

这样的逻辑是正确的，而共同性的问题一般不来源于此，而是呈现在处理写恳求的时分。所以咱们简化成最简略的写恳求的逻辑，此刻你或许会面临多个挑选，究竟是直接更新缓存，仍是失效缓存？而不管是更新缓存仍是失效缓存，都能够挑选在更新数据库之前，仍是之后操作。

这样就演变出 4 个战略：更新数据库后更新缓存、更新数据库前更新缓存、更新数据库后删去缓存、更新数据库前删去缓存。下面咱们来分别叙述。

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

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

咱们想象一下这样的场景。

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

可是特殊场景下，你或许会遇到这样的状况：

线程 A 和线程 B 一起更新这个数据

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

更新缓存时次序是先 B 后 A
假设咱们的代码逻辑仍是更新数据库后马上更新缓存的数据，那么——

updateMySQL();
updateRedis(key, data);

就或许呈现：数据库的值是 100->99->98，可是缓存的数据却是 100->98->99，也就是数据库与缓存的不共同。并且这个不共同只能比及下一次数据库更新或许缓存失效才或许修复。

时刻	线程A（写恳求）	线程B（写恳求）	问题
T1	更新数据库为99
T2	更新数据库为98
T3	更新缓存数据为98
T4	更新缓存数据为99	此刻缓存的值被显式更新为99，可是实际上数据库的值现已是98，数据不共同

当然，假设更新Redis自身是失利的话，两头的值当然也是不共同的，这个前文也阐述过，简直无法铲除。

（二）更新数据库前更新缓存的不共同问题

那你或许会想，这是否表明，我应该先让缓存更新，之后再去更新数据库呢？相似这样：

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

这样操作产生的问题更是显而易见的，由于咱们无法确保数据库的更新成功，假设数据库更新失利了，你缓存的数据就不仅仅脏数据，而是过错数据了。

你或许会想，是否我在更新数据库失利的时分做 Redis 回滚的操作能够处理呢？这其实也是不靠谱的，由于咱们也不能确保这个回滚的操作 100% 被成功履行。
一起，在写写并发的场景下，相同有相似的共同性问题，请看以下状况：

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

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

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

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

时刻	线程A（写请****求）	线程B（写恳求）	问题
T1	更新缓存为0
T2	更新缓存为1
T3	更新数据库为1
T4	更新数据库数据为0	此刻缓存的值被显式更新为1，可是实际上数据库的值是0，数据不共同

所以通常状况下，更新缓存再更新数据库是咱们应该防止运用的一种手法。

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

那假设采纳删去缓存的战略呢？也就是说咱们在更新数据库的时分失效对应的缓存，让缓存在下次触发读恳求时进行更新，是否会更好呢？相同地，针对在更新数据库前和数据库后这两个删去机遇，咱们来比较下其差异。

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

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

这样的逻辑看似没有问题，究竟删去缓存后即使数据库更新失利了，也仅仅缓存上没有数据罢了。然后并发两个写恳求过来，不管怎么样的履行次序，缓存终究的值也都是会被删去的，也就是说在并发写写的恳求下这样的处理是没问题的。

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

仍是刚刚更新计数的例子。例如现在缓存的数据是 100，数据库也是 100，这时分需求对此计数减 1，减成功后，数据库应该是 99。假设这之后触发读恳求，缓存假设有用的话，里边应该也要被更新为 99 才是正确的。

那么考虑下这样的恳求状况：

线程 A 更新这个数据的一起，线程 B 读取这个数据

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

线程 A 更新数据库成功

时刻	线程A（写恳求）	线程B（读恳求）	问题
T1	删去缓存值
T2	1.读取缓存数据，缓存缺失，从数据库读取数据100
T3	更新数据库中的数据X的值为99
T4	将数据100的值写入缓存	此刻缓存的值被显式更新为100，可是实际上数据库的值现已是99了

能够看到，在读写并发的场景下，一样会有不共同的问题。

针对这种场景，有个做法是所谓的“推迟双删战略”，就是说，已然或许由于读恳求把一个旧的值又写回去，那么我在写恳求处理完之后，比及差不多的时刻推迟再从头删去这个缓存值。

时刻	线程A（写恳求 ）	线程C（新的读恳求）	线程D（新的读恳求）	问题
T5	sleep(N)	缓存存在，读取到缓存旧值100	其他线程或许在双删成功前读到脏数据
T6	删去缓存值
T7	缓存缺失，从数据库读取数据的最新值（99）

这种处理思路的关键在于对 N 的时刻的判断，假设 N 时刻太短，线程 A 第2次删去缓存的时刻仍旧早于线程 B 把脏数据写回缓存的时刻，那么相当于做了无用功。而 N 假设设置得太长，那么在触发双删之前，新恳求看到的都是脏数据。

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

那假设咱们把更新数据库放在删去缓存之前呢，问题是否处理？咱们持续从读写并发的场景看下去，有没有相似的问题。

时刻	线程A（写恳求）	线程B（读恳求）	线程C（读恳求）	潜在问题
T1	更新主库 X = 99（原值 X = 100）
T2	读取数据，查询到缓存还有数据，回来100	线程C实际上读取到了和数据库不共同的数据
T3	删去缓存
T4	查询缓存，缓存缺失，查询数据库得到当时值99
T5	将99写入缓存

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

而在开篇的时分咱们说过，缓存不共同性的问题无法在客观上彻底消除，由于咱们无法确保数据库和缓存的操作是一个事务里的，而咱们能做到的仅仅尽量缩短不共同的时刻窗口。

在更新数据库后删去缓存这个场景下，不共同窗口仅仅是 T2 到 T3 的时刻，内网状态下通常不过 1ms，在大部分事务场景下咱们都能够忽略不计。由于大部分状况下一个用户的恳求很难能再1ms内快速发起第2次。

可是实在场景下，仍是会有一个状况存在不共同的或许性，这个场景是读线程发现缓存不存在，于是读写并发时，读线程回写进去老值。并发状况如下：

时刻	线程A（写恳求）	线程B（读恳求–缓存不存在场景）	潜在问题
T1	查询缓存，缓存缺失，查询数据库得到当时值100
T2	更新主库 X = 99（原值 X = 100）
T3	删去缓存
T4	将100写入缓存	此刻缓存的值被显式更新为100，可是实际上数据库的值现已是99了

总的来说，这个不共同场景呈现条件十分严厉，由于并发量很大时，缓存不太或许不存在；假设并发很大，而缓存真的不存在，那么很或许是这时的写场景很多，由于写场景会删去缓存。

所以待会咱们会说到，写场景很多时分实际上并不合适采纳删去战略。

（五）总结四种更新战略

终上所述，咱们对比了四个更新缓存的手法，做一个总结对比，其中应对方案也供给参考，详细不做展开，如下表：

战略	并发场景	潜在问题	应对方案
更新数据库+更新缓存	写+读	线程A未更新完缓存之前，线程B的读恳求会时刻短读到旧值	能够忽略
写+写	更新数据库的次序是先A后B，但更新缓存时次序是先B后A，数据库和缓存数据不共同	分布式锁（操作重）
更新缓存+更新数据库	无并发	线程A还未更新完缓存可是更新数据库或许失利	运用MQ确认数据库更新成功（较杂乱）
写+写	更新缓存的次序是先A后B，但更新数据库时次序是先B后A	分布式锁（操作很重）
删去缓存值+更新数据库	写+读	写恳求的线程A删去了缓存在更新数据库之前，这时分读恳求线程B到来，由于缓存缺失，则把当时数据读取出来放到缓存，而后线程A更新成功了数据库	推迟双删（可是推迟的时刻不好估计，且推迟的过程中仍旧有不共同的时刻窗口）
更新数据库+删去缓存值	写+读（缓存射中）	线程A完成数据库更新成功后，没有删去缓存，线程B有并发读恳求会读到旧的脏数据	能够忽略
写+读（缓存不射中）	读恳求不射中缓存，写恳求处理完之后读恳求才回写缓存，此刻缓存不共同	分布式锁（操作重）

从共同性的视点来看，采纳更新数据库后删去缓存值，是更为合适的战略。由于呈现不共同的场景的条件更为严苛，概率相比其他方案更低。

那么是否更新缓存这个战略就一无可取呢？不是的！

删去缓存值意味着对应的 key 会失效，那么这时分读恳求都会打到数据库。假设这个数据的写操作十分频频，就会导致缓存的效果变得十分小。而假设这时分某些 Key 仍是十分大的热 key，就或许由于扛不住数据量而导致体系不可用。

如下图所示：

删去战略频频的缓存失效导致读恳求无法运用缓存

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

针对大部分读多写少场景，主张挑选更新数据库后删去缓存的战略。

针对读写相当或许写多读少的场景，主张挑选更新数据库后更新缓存的战略。

终究共同性怎么确保？

缓存设置过期时刻

第一个方法就是咱们上面说到的，当咱们无法确定 MySQL 更新完成后，缓存的更新/删去必定能成功，例如 Redis 挂了导致写入失利了，或许当时网络呈现故障，更常见的是服务当时刚好发生重启了，没有履行这一步的代码。
这些时分 MySQL 的数据就无法刷到 Redis 了。为了防止这种不共同性永久存在，运用缓存的时分，咱们有必要要给缓存设置一个过期时刻，例如 1 分钟，这样即使呈现了更新 Redis 失利的极点场景，不共同的时刻窗口最多也仅仅 1 分钟。
这是咱们终究共同性的兜底方案，假设呈现任何状况的不共同问题，终究都能通过缓存失效后从头查询数据库，然后回写到缓存，来做到缓存与数据库的终究共同。

怎么削减缓存删去/更新的失利？

假设删去缓存这一步由于服务重启没有履行，或许 Redis 暂时不可用导致删去缓存失利了，就会有一个较长的时刻（缓存的剩余过期时刻）是数据不共同的。

那咱们有没有什么手法来削减这种不共同的状况呈现呢？这时分借助一个可靠的音讯中间件就是一个不错的挑选。

由于音讯中间件有 ATLEAST-ONCE 的机制，如下图所示。

咱们把删去 Redis 的恳求以消费 MQ 音讯的手法去失效对应的 Key 值，假设 Redis 真的存在异常导致无法删去成功，咱们仍旧能够依托 MQ 的重试机制来让终究 Redis 对应的 Key 失效。

而你们或许会问，极点场景下，是否存在更新数据库后 MQ 音讯没发送成功，或许没时机发送出去机器就重启的状况？

这个场景的确比较麻烦，假设 MQ 运用的是 RocketMQ，咱们能够借助 RocketMQ 的事务音讯，来让删去缓存的音讯终究必定发送出去。而假设你没有运用 RocketMQ，或许你运用的音讯中间件并没有事务音讯的特性，则能够采纳音讯表的方法让更新数据库和发送音讯一起成功。事实上这个话题比较大了，咱们不在这儿展开。

怎么处理杂乱的多缓存场景？

有些时分，实在的缓存场景并不是数据库中的一个记载对应一个 Key 这么简略，有或许一个数据库记载的更新会牵扯到多个 Key 的更新。还有别的一个场景是，更新不同的数据库的记载时或许需求更新同一个 Key 值，这常见于一些 App 首页数据的缓存。

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

假设体系规划上咱们缓存了一个粉丝的主页信息、主播打赏榜 TOP10 的粉丝、单日 TOP 100 的粉丝等多个信息。假设这个粉丝注销了，或许这个粉丝触发了打赏的行为，上面多个 Key 或许都需求更新。仅仅一个打赏的记载，你或许就要做：

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

这就涉及多个 Redis 的操作，每一步都或许失利，影响到后边的更新。乃至从体系规划上，更新数据库或许是独自的一个服务，而这几个不同的 Key 的缓存保护却在不同的 3 个微服务中，这就大大增加了体系的杂乱度和提高了缓存操作失利的或许性。最可怕的是，操作更新记载的当地很大概率不只在一个事务逻辑中，而是散发在体系各个零星的位置。

针对这个场景，处理方案和上文说到的确保终究共同性的操作一样，就是把更新缓存的操作以 MQ 音讯的方法发送出去，由不同的体系或许专门的一个体系进行订阅，而做聚合的操作。如下图：

不同事务体系订阅MQ音讯独自保护各自的缓存Key

专门更新缓存的服务订阅MQ音讯保护所有相关Key的缓存操作

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

上面讲到的 MQ 处理方法需求事务代码里边显式地发送 MQ 音讯。还有一种高雅的方法就是订阅 MySQL 的 binlog，监听数据的实在改变状况以处理相关的缓存。

例如刚刚说到的例子中，假设粉丝又触发打赏了，这时分咱们运用 binlog 表监听是能及时发现的，发现后就能会集处理了，并且不管是在什么体系什么位置去更新数据，都能做到会集处理。

现在业界相似的产品有 Canal，详细的操作图如下：

运用Canel订阅数据库binlog变更然后发出MQ音讯，让一个专门顾客服务保护所有相关Key的缓存操作

到这儿，针对大型体系缓存规划怎么确保终究共同性，咱们现已从战略、场景、操作方案等视点进行了细致的叙述，期望能对你起到协助。

注：本文基于自己博客jaskey.github.io/blog/2022/0…

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