redis相关-数据库和缓存如何保证一致性？

前言

问题的实质：

这些问题根本是因为高并发问题！
以及
并非原子性操作
而且还有主从延迟的问题

一致性

“数据⼀致”指的是：缓存中有数据，缓存的数据值 = 数据库中的值。

一致性需要满足两个条件

• 消除其他并发线程的影响 脏数据
• 数据库和缓存操作是原子操作，可能其中一个成功而另一个失败
  • 数据库操作成功而缓存失败 这时候如果缓存有过期时间且不太长 那么还不会这么严重
  • 缓存成功而数据库失败 这个问题很严重

但是 原子操作一般来说 不太会失败 所以如果项目要求不是特别高 就算了

参考文章

小林coding

知乎Kaito​ 他的公众号是「水滴与银弹」 写的很好

https://www.zhihu.com/question/319817091/answer/2176813916 鹅厂架构师

https://www.zhihu.com/question/458352302/answer/2309776827 互联网科技小于哥

这四个写的都很好

先更新数据库，还是先更新缓存？

由于引入了缓存，那么在数据更新时，不仅要更新数据库，而且要更新缓存，这两个更新操作存在前后的问题：

• 先更新数据库，再更新缓存；
• 先更新缓存，再更新数据库；

阿旺没想到太多，他觉得最新的数据肯定要先更新数据库，这样才可以确保数据库里的数据是最新的，于是他就采用了「先更新数据库，再更新缓存」的方案。

先更新数据库，再更新缓存

这是我们最容易想到的方案

• 高并发下 出现了缓存和数据库中的数据不一致的现象
• 如果更新数据库和缓存有一个不成功，则会出问题

先更新缓存，再更新数据库

• 发现高并发下最终数据库的值和缓存的值还是可能对不上
• 如果更新数据库和缓存有一个不成功，则会出问题

结论与解决

无论是「先更新数据库，再更新缓存」，还是「先更新缓存，再更新数据库」，这两个方案都存在并发问题，当两个请求并发更新同一条数据的时候，可能会出现缓存和数据库中的数据不一致的现象。以及如果更新数据库和缓存有一个不成功，则会出问题。

但是，如果我们的业务对缓存命中率有很高的要求，我们可以采用「先更新数据库，再更新缓存」的方案，因为更新缓存并不会出现缓存未命中的情况。

但是这个方案前面我们也分析过，在两个更新请求并发执行的时候，会出现数据不一致的问题，因为更新数据库和更新缓存这两个操作是独立的，而我们又没有对操作做任何并发控制，那么当两个线程并发更新它们的话，就会因为写入顺序的不同造成数据的不一致。

所以我们得增加一些手段来解决这个问题，这里提供两种做法：

• 在更新完缓存时，给缓存加上较短的过期时间，这样即时出现缓存不一致的情况，缓存的数据也会很快过期，对业务还是能接受的。
• 在更新缓存前先加个分布式锁，保证同一时间只运行一个请求更新缓存，就会不会产生并发问题了，当然引入了锁后，对于写入的性能就会带来影响。如果读多写少还好，写操作一旦多一点就很影响性能了。

关于第二点，解决不一致的方案通常都是加「分布式锁」。

两个线程要修改「同一条」数据，每个线程在改之前，先去申请分布式锁，拿到锁的线程才允许更新数据库和缓存，拿不到锁的线程，返回失败，等待下次重试。

这么做的目的，就是为了只允许一个线程去操作数据和缓存，避免并发问题。

其中，分布式锁的实现可以使⽤以下策略：

除此之外，我们从「缓存利用率」的角度来评估这个方案，也是不太推荐的。

这是因为每次数据发生变更，都「无脑」更新缓存，但是缓存中的数据不一定会被「马上读取」，这就会导致缓存中可能存放了很多不常访问的数据，浪费缓存资源。

而且很多情况下，写到缓存中的值，并不是与数据库中的值一一对应的，很有可能是先查询数据库，再经过一系列「计算」得出一个值，才把这个值才写到缓存中。

由此可见，这种「更新数据库 + 更新缓存」的方案，不仅缓存利用率不高，还会造成机器性能的浪费。

而且，还是不能保证原子操作，其中一个步骤可能会失败

第三种做法就是下文提到的旁路缓存策略了

旁路缓存策略 Cache Aside——不更新缓存而是删除缓存

Cache Aside：在更新数据时，不更新缓存，而是删除缓存中的数据。然后，到读取数据时，发现缓存中没了数据之后，再从数据库中读取数据，更新到缓存中。

写策略和读策略

该策略又可以细分为「读策略」和「写策略」。

写策略的步骤：

• 更新数据库中的数据；
• 删除缓存中的数据。

读策略的步骤：

• 如果读取的数据命中了缓存，则直接返回数据；
• 如果读取的数据没有命中缓存，则从数据库中读取数据，然后将数据写入到缓存，并且返回给用户。

阿旺在想到「写策略」的时候，又陷入更深层次的思考，到底该选择哪种顺序呢？

• 先删除缓存，再更新数据库；
• 先更新数据库，再删除缓存。
  阿旺这次经过上次教训，不再「想当然」的乱选方案

写策略之——先删除缓存，再更新数据库（不能满足要求）

可以看到，先删除缓存，再更新数据库，在「读 + 写」并发的时候，还是会出现缓存和数据库的数据不一致的问题。

如何解决——延迟双删

第一个问题，还记得前面讲到的「先删除缓存，再更新数据库」导致不一致的场景么？

这里我再把例子拿过来让你复习一下：

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 个问题的核心在于：缓存都被回种了「旧值」。

那怎么解决这类问题呢？

最有效的办法就是，把缓存删掉。

但是，不能立即删，而是需要「延迟删」，这就是业界给出的方案：缓存延迟双删策略。

针对「先删除缓存，再更新数据库」方案在「读 + 写」并发请求而造成缓存不一致的解决办法是「延迟双删」。

延迟双删实现的伪代码如下：

#删除缓存
redis.delKey(X)
#更新数据库
db.update(X)
#睡眠
Thread.sleep(N)
#再删除缓存
redis.delKey(X)

如果难以接受sleep这种写法，可以使⽤延时队列进⾏替代。

加了个睡眠时间，主要是为了确保请求 A 在睡眠的时候，请求 B 能够在这这一段时间完成「从数据库读取数据，再把缺失的缓存写入缓存」的操作，然后请求 A 睡眠完，再删除缓存。

所以，请求 A 的睡眠时间就需要大于请求 B 「从数据库读取数据 + 写入缓存」的时间。

但是具体睡眠多久其实是个玄学，很难评估出来，所以这个方案也只是尽可能保证一致性而已，极端情况下，依然也会出现缓存不一致的现象。

按照延时双删策略，这 2 个问题的解决方案是这样的：

解决第一个问题：在线程 A 删除缓存、更新完数据库之后，先「休眠一会」，再「删除」一次缓存。

解决第二个问题：线程 A 可以生成一条「延时消息」，写到消息队列中，消费者延时「删除」缓存。

这两个方案的目的，都是为了把缓存清掉，这样一来，下次就可以从数据库读取到最新值，写入缓存。

但问题来了，这个「延迟删除」缓存，延迟时间到底设置要多久呢？

问题1：延迟时间要大于「主从复制」的延迟时间
问题2：延迟时间要大于线程 B 读取数据库 + 写入缓存的时间
但是，这个时间在分布式和高并发场景下，其实是很难评估的。

很多时候，我们都是凭借经验大致估算这个延迟时间，例如延迟 1-5s，只能尽可能地降低不一致的概率。

所以你看，采用这种方案，也只是尽可能保证一致性而已，极端情况下，还是有可能发生不一致。

但其实这背后还有一个问题，那就是如果删除的数据是一个热点数据，是有可能造成缓存击穿+的。针对这个问题，国外的 Facebook 给出了一个解决方案，就是在删除的时候，如果判定这是一个热门数据，那么不直接删，而是将它的生命周期设置的更短一些，比如 10 到 30 秒，然后业务方在调用的时候会表明这是一个脏数据。至于你要不要用，则交给业务方进行判断。

因此，还是比较建议用「先更新数据库，再删除缓存」的方案。

写策略之——（同步删除）先更新数据库，再删除缓存（基本满足要求）

最终，该用户年龄在缓存中是 20（旧值），在数据库中是 21（新值），缓存和数据库数据不一致。

从上面的理论上分析，先更新数据库，再删除缓存也是会出现数据不一致性的问题，这种情况「理论」来说是可能发生的，但实际真的有可能发生吗？在实际中，这个问题出现的概率并不高。

其实概率「很低」，这是因为它必须满足 3 个条件：

• 缓存刚好已失效
• 读请求 + 写请求并发
• 更新数据库操作在读数据库操作之后，且更新数据库 + 删除缓存的时间，要比读数据库 + 写缓存时间短
  仔细想一下，条件 3 发生的概率其实是非常低的。

因为写数据库一般会先「加锁」，所以写数据库，通常是要比读数据库的时间更长的。而且缓存的写入通常要远远快于数据库的写入，所以在实际中很难出现请求 B 已经更新了数据库并且删除了缓存，请求 A 才更新完缓存的情况。
更何况此时 是读数据库+写缓存操作先发生。

而一旦请求 A 早于请求 B 删除缓存之前更新了缓存，那么接下来的请求就会因为缓存不命中而从数据库中重新读取数据，所以不会出现这种不一致的情况。

当然 这也意味着 我们需要尽量减少读数据库+写缓存操作中间的间隔，不要让它们太长 比如中间加很多计算的逻辑

注意 和先更新数据库还是先更新缓存那里不一样，那里是两个写操作，而这里是读写

在"先更新数据库，再删除缓存"方案下，"读写分离 + 主从库延迟”也会导致缓存和数据库不一致，缓解此问题的方案是凭借经验发送延迟消息到队列中，延迟删除缓存，同时也要控制主从库延迟，尽可能降低不一致发生的概率

所以，「先更新数据库 + 再删除缓存」的方案，是可以保证数据一致性的。
而且阿旺为了确保万无一失，还给缓存数据加上了**「过期时间」**，就算在这期间存在缓存数据不一致，有过期时间来兜底，这样也能达到最终一致。

好，解决了并发问题，我们继续来看前面遗留的，第二步执行「失败」导致数据不一致的问题。

如何解决原子性操作问题

「先更新数据库， 再删除缓存」其实是两个操作，前面的所有分析都是建立在这两个操作都能同时执行成功，而这次客户投诉的问题就在于，在删除缓存（第二个操作）的时候失败了，导致缓存中的数据是旧值。

好在之前给缓存加上了过期时间，所以才会出现客户说的过一段时间才更新生效的现象，假设如果没有这个过期时间的兜底，那后续的请求读到的就会一直是缓存中的旧数据，这样问题就更大了。

第一种方法是重试。

无论是先操作缓存，还是先操作数据库，但凡后者执行失败了，我们就可以发起重试，尽可能地去做「补偿」。

那这是不是意味着，只要执行失败，我们「无脑重试」就可以了呢？

答案是否定的。现实情况往往没有想的这么简单，失败后立即重试的问题在于：

立即重试很大概率「还会失败」
「重试次数」设置多少才合理？
重试会一直「占用」这个线程资源，无法服务其它客户端请求

看到了么，虽然我们想通过重试的方式解决问题，但这种「同步」重试的方案依旧不严谨。

那更好的方案应该怎么做？

答案是：异步重试。

文章1

什么是异步重试？

其实就是把重试请求写到「消息队列」中，然后由专门的消费者来重试，直到成功。

或者更直接的做法，为了避免第二步执行失败，我们可以把操作缓存这一步，直接放到消息队列中，由消费者来操作缓存。

到这里你可能会问，写消息队列也有可能会失败啊？而且，引入消息队列，这又增加了更多的维护成本，这样做值得吗？

这个问题很好，但我们思考这样一个问题：如果在执行失败的线程中一直重试，还没等执行成功，此时如果项目「重启」了，那这次重试请求也就「丢失」了，那这条数据就一直不一致了。

所以，这里我们必须把重试消息或第二步操作放到另一个「服务」中，这个服务用「消息队列」最为合适。这是因为消息队列的特性，正好符合我们的需求：

消息队列保证可靠性：写到队列中的消息，成功消费之前不会丢失（重启项目也不担心）
消息队列保证消息成功投递：下游从队列拉取消息，成功消费后才会删除消息，否则还会继续投递消息给消费者（符合我们重试的需求）

至于写队列失败和消息队列的维护成本问题：

写队列失败：操作缓存和写消息队列，「同时失败」的概率其实是很小的
维护成本：我们项目中一般都会用到消息队列，维护成本并没有新增很多

所以，引入消息队列来解决这个问题，是比较合适的。这时架构模型就变成了这样：

那如果你确实不想在应用中去写消息队列，是否有更简单的方案，同时又可以保证一致性呢？

方案还是有的，这就是近几年比较流行的解决方案：订阅数据库变更日志，再操作缓存。

具体来讲就是，我们的业务应用在修改数据时，「只需」修改数据库，无需操作缓存。

那什么时候操作缓存呢？这就和数据库的「变更日志」有关了。

拿 MySQL 举例，当一条数据发生修改时，MySQL 就会产生一条变更日志（Binlog），我们可以订阅这个日志，拿到具体操作的数据，然后再根据这条数据，去删除对应的缓存。

订阅变更日志，目前也有了比较成熟的开源中间件，例如阿里的 canal，使用这种方案的优点在于：

无需考虑写消息队列失败情况：只要写 MySQL 成功，Binlog 肯定会有
自动投递到下游队列：canal 自动把数据库变更日志「投递」给下游的消息队列
当然，与此同时，我们需要投入精力去维护 canal 的高可用和稳定性。

如果你有留意观察很多数据库的特性，就会发现其实很多数据库都逐渐开始提供「订阅变更日志」的功能了，相信不远的将来，我们就不用通过中间件来拉取日志，自己写程序就可以订阅变更日志了，这样可以进一步简化流程。
至此，我们可以得出结论，想要保证数据库和缓存一致性，推荐采用「先更新数据库，再删除缓存」方案，并配合「消息队列」或「订阅变更日志」的方式来做。

文章2

前面提到了，这个步骤的问题在于，「先更新数据库， 再删除缓存」其实是两个操作，前面的所有分析都是建立在这两个操作都能同时执行成功。

所以新的问题来了，如何保证「先更新数据库 ，再删除缓存」这两个操作能执行成功？

其实不管是先操作数据库，还是先操作缓存，只要第二个操作失败都会出现数据一致的问题。

问题原因知道了，该怎么解决呢？有两种方法：

• 消息队列重试机制。
• 订阅 MySQL binlog，再操作缓存。

消息队列重试机制

我们可以引入消息队列，将第二个操作（删除缓存）要操作的数据加入到消息队列，由消费者来操作数据。

如果应用删除缓存失败，可以从消息队列中重新读取数据，然后再次删除缓存，这个就是重试机制。当然，如果重试超过的一定次数，还是没有成功，我们就需要向业务层发送报错信息了。
如果删除缓存成功，就要把数据从消息队列中移除，避免重复操作，否则就继续重试。
举个例子，来说明重试机制的过程。

这个方案缺点是，对代码入侵性比较强，因为需要改造原本业务的代码。

订阅 MySQL binlog，再操作缓存

「先更新数据库，再删缓存」的策略的第一步是更新数据库，那么更新数据库成功，就会产生一条变更日志，记录在 binlog 里。

于是我们就可以通过订阅 binlog 日志，拿到具体要操作的数据，然后再执行缓存删除，阿里巴巴开源的 Canal 中间件就是基于这个实现的。

Canal 模拟 MySQL 主从复制的交互协议，把自己伪装成一个 MySQL 的从节点，向 MySQL 主节点发送 dump 请求，MySQL 收到请求后，就会开始推送 Binlog 给 Canal，Canal 解析 Binlog 字节流之后，转换为便于读取的结构化数据，供下游程序订阅使用。

下图是 Canal 的工作原理：

前面我们说到直接用消息队列重试机制方案的话，会对代码造成入侵，那么 Canal 方案就能很好的规避这个问题，因为它是直接订阅 binlog 日志的，和业务代码没有藕合关系，因此我们可以通过 Canal+ 消息队列的方案来保证数据缓存的一致性。

具体的做法是：将binlog日志采集发送到MQ队列里面，然后编写一个简单的缓存删除消息者订阅binlog日志，根据更新log删除缓存，并且通过ACK机制确认处理这条更新log，保证数据缓存一致性

这里有一个很关键的点，必须是删除缓存成功，再回 ack 机制给消息队列，否则可能会造成消息丢失的问题，比如消费服务从消息队列拿到事件之后，直接回了 ack，然后再执行删除缓存操作的话，如果删除缓存的操作还是失败了，那么因为提前给消息队列回 ack了，就没办重试了。

所以，如果要想保证「先更新数据库，再删缓存」策略第二个操作能执行成功，我们可以使用：

消息队列来重试缓存的删除，优点是保证缓存一致性的问题，缺点会对业务代码入侵
订阅 MySQL binlog + 消息队列 + 重试缓存的删除，优点是规避了代码入侵问题，也很好的保证缓存一致性的问题，缺点就是引入的组件比较多，对团队的运维能力比较有高要求。
这两种方法有一个共同的特点，都是采用异步操作缓存

主从延迟场景的问题

回顾下延迟双删那个例子

如何解决缓存穿透问题

这两种方案有可能导致请求因缓存缺失而访问数据库，给数据库带来压力，也就是缓存穿透的问题。针对缓存穿透问题，可以⽤缓存空结果、布隆过滤器进⾏解决。

可以做到强一致吗？

看到这里你可能会想，这些方案还是不够完美，我就想让缓存和数据库「强一致」，到底能不能做到呢？

其实很难。

要想做到强一致，最常见的方案是 2PC、3PC、Paxos、Raft 这类一致性协议，但它们的性能往往比较差，而且这些方案也比较复杂，还要考虑各种容错问题。

相反，这时我们换个角度思考一下，我们引入缓存的目的是什么？
没错，性能。

一旦我们决定使用缓存，那必然要面临一致性问题。性能和一致性就像天平的两端，无法做到都满足要求。

而且，就拿我们前面讲到的方案来说，当操作数据库和缓存完成之前，只要有其它请求可以进来，都有可能查到「中间状态」的数据。

所以如果非要追求强一致，那必须要求所有更新操作完成之前期间，不能有「任何请求」进来。

虽然我们可以通过加「分布锁」的方式来实现，但我们也要付出相应的代价，甚至很可能会超过引入缓存带来的性能提升。

所以，既然决定使用缓存，就必须容忍「一致性」问题，我们只能尽可能地去降低问题出现的概率。

​同时我们也要知道，缓存都是有「失效时间」的，就算在这期间存在短期不一致，我们依旧有失效时间来兜底，这样也能达到最终一致。

总结

好了，总结一下这篇文章的重点。

1、想要提高应用的性能，可以引入「缓存」来解决。记住这点，缓存主要是为了提高性能，所以一般不要去费力去做强一致性，我们追求最终一致性即可。下面大多数高并发下数据不一致的情况都可以分布式锁解决，但是严重影响性能。

2、引入缓存后，需要考虑缓存和数据库一致性问题，可选的方案有：「更新数据库 + 更新缓存」、「更新数据库 + 删除缓存」。但是无论哪种方案，都需要设置缓存过期时间兜底。

3、更新数据库 + 更新缓存方案，在「并发」场景下无法保证缓存和数据一致性，解决方案是加「分布锁」，但这种方案存在「缓存资源浪费」和「机器性能浪费」的情况。而且也无法保证原子性。
但是优点是缓存命中率高和实现简单。如果我们的业务对缓存命中率有很高的要求，我们可以采用「先更新数据库，再更新缓存」的方案，因为更新缓存并不会出现缓存未命中的情况。

4、采用「先删除缓存，再更新数据库」方案，在「并发」场景下依旧有不一致问题，解决方案是「延迟双删」，但这个延迟时间很难评估。而且也无法保证原子性。以及存在缓存击穿的情况。

5、采用「先更新数据库，再删除缓存」方案，通常情况下不会在高并发环境下出问题，为了保证两步都成功执行，需配合「消息队列」或「订阅变更日志」的方案来做，本质是通过「重试」的方式保证数据最终一致。

6、采用「先更新数据库，再删除缓存」，「读写分离 + 主从库延迟」也会导致缓存和数据库不一致，缓解此问题的方案是「延迟双删」，凭借经验发送「延迟消息」到队列中，延迟删除缓存，同时也要控制主从库延迟，尽可能降低不一致发生的概率。以及存在缓存击穿的情况。

7、旁路缓存策略，为了应对缓存穿透问题，可以⽤缓存空结果、布隆过滤器进⾏解决。

8、为了避免缓存击穿，如果删除的是热门数据，那么建议采用不直接删除，而是设置一个较短的生命周期。业务方在获取数据的时候，告诉它这是一个旧数据，是否使用由你来决定

9、原子操作一般来说 不太会失败 所以如果项目要求不是特别高 就算了

其他需要注意的问题：

• redis:k-v大小的合理设置:Redis key大小设计： 由于⽹络的⼀次传输MTU最⼤为1500字节，所以为了保证⾼效的性能，建议单个k-v⼤⼩不超过1KB，⼀次 ⽹络传输就能完成，避免多次⽹络交互；k-v是越⼩性能越好
• Redis 热key：（1） 当业务遇到单个读热key，通过增加副本来提⾼读能⼒或是⽤hashtag把key存多份在 多个分⽚中；（2）当业务遇到单个写热key，需业务拆分这个key的功能，属于设计不合理-当业务遇到热分片，即多个热key在同⼀个分片上导致单分片cpu⾼，可通过hashtag⽅式打散
• redis其他问题
  
• 机器故障问题

所以，最终推荐的策略是：
先更新数据库，再删除缓存。
首先缓存需要过期时间来兜底
其中，删除缓存用cannal+订阅binlog+延时队列来做。
同时 ，应用布隆过滤器来或者短时缓存空结果来解决缓存击穿问题，以及可以参考在删除的时候，如果判定这是一个热门数据，那么不直接删，而是将它的生命周期设置的更短些，比如 10 到 30 秒，然后业务方在调用的时候会表明这是一个脏数据。至于你要不要用，则交给业务方进行判断。

终极方案（没写好··）

终极方案

核心流程：

1. 删除数据库同步删除缓存：
   缩小可能发生脏数据的时间窗

2. Binlog + MQ删除缓存：
   兜底所有入口，避免遗漏删除缓存场景，同时通过MQ的消息重试保证缓存一定删除成功

3. 监听Binlog延迟N秒进行数据一致性校验：
   每个更新操作后延迟校验数据库与缓存的一致性，异常则修复，解决极端场景下的脏数据问题

4. 过期删除缓存：
   刚更新过的缓存存在不一致性的概率相对会大很多，因此可以在更新场景下设置更小的过期时间

5. 存在数据库更新的链路禁用缓存：
   因为数据库更新后，立刻查询缓存，缓存可能还没来的及更新，此时可直接查询数据库降低读脏数据风险

6. 【集群问题】强制读Redis主节点：
   更新Redis后，立刻读取，如果读的是从节点，可能数据不是最新的，此时可强制读主节点降低读脏数据风险

7. 【监控分析】查询异步数据一致性校验：
   查询完数据库之后，通过线程池再异步的查一次缓存，将数据库数据和缓存数据做比较，结果进行打点统计，如果概率超1%说明流程还不可靠，需分析不一致性数据，分析原因，继续优化。如果概率小于0.01%，证明流量基本可靠。

8. 【灰度放量】新方案试点后再逐步放开：
   没有经过线上验证的方案，不要全切，让风险可控，逐步放开