极客时间已完结课程限时免费阅读

25 | 缓存异常（上）：如何解决缓存和数据库的数据不一致问题？

25 | 缓存异常（上）：如何解决缓存和数据库的数据不一致问题？-极客时间

25 | 缓存异常（上）：如何解决缓存和数据库的数据不一致问题？

2020-10-14 蒋德钧 来自北京
《Redis核心技术与实战》
课程介绍

讲述：蒋德钧

时长13:34大小12.40M

你好，我是蒋德钧。
在实际应用 Redis 缓存时，我们经常会遇到一些异常问题，概括来说有 4 个方面：缓存中的数据和数据库中的不一致；缓存雪崩；缓存击穿和缓存穿透。
只要我们使用 Redis 缓存，就必然会面对缓存和数据库间的一致性保证问题，这也算是 Redis 缓存应用中的“必答题”了。最重要的是，如果数据不一致，那么业务应用从缓存中读取的数据就不是最新数据，这会导致严重的错误。比如说，我们把电商商品的库存信息缓存在 Redis 中，如果库存信息不对，那么业务层下单操作就可能出错，这当然是不能接受的。所以，这节课我就重点和你聊聊这个问题。关于缓存雪崩、穿透和击穿等问题，我会在下一节课向你介绍。
接下来，我们就来看看，缓存和数据库之间的数据不一致是怎么引起的。

缓存和数据库的数据不一致是如何发生的？

首先，我们得清楚“数据的一致性”具体是啥意思。其实，这里的“一致性”包含了两种情况：
缓存中有数据，那么，缓存的数据值需要和数据库中的值相同；
缓存中本身没有数据，那么，数据库中的值必须是最新值。
不符合这两种情况的，就属于缓存和数据库的数据不一致问题了。不过，当缓存的读写模式不同时，缓存数据不一致的发生情况不一样，我们的应对方法也会有所不同，所以，我们先按照缓存读写模式，来分别了解下不同模式下的缓存不一致情况。我在第 23 讲中讲过，根据是否接收写请求，我们可以把缓存分成读写缓存和只读缓存。
对于读写缓存来说，如果要对数据进行增删改，就需要在缓存中进行，同时还要根据采取的写回策略，决定是否同步写回到数据库中。
同步直写策略：写缓存时，也同步写数据库，缓存和数据库中的数据一致；
异步写回策略：写缓存时不同步写数据库，等到数据从缓存中淘汰时，再写回数据库。使用这种策略时，如果数据还没有写回数据库，缓存就发生了故障，那么，此时，数据库就没有最新的数据了。
所以，对于读写缓存来说，要想保证缓存和数据库中的数据一致，就要采用同步直写策略。不过，需要注意的是，如果采用这种策略，就需要同时更新缓存和数据库。所以，我们要在业务应用中使用事务机制，来保证缓存和数据库的更新具有原子性，也就是说，两者要不一起更新，要不都不更新，返回错误信息，进行重试。否则，我们就无法实现同步直写。
当然，在有些场景下，我们对数据一致性的要求可能不是那么高，比如说缓存的是电商商品的非关键属性或者短视频的创建或修改时间等，那么，我们可以使用异步写回策略。
下面我们再来说说只读缓存。对于只读缓存来说，如果有数据新增，会直接写入数据库；而有数据删改时，就需要把只读缓存中的数据标记为无效。这样一来，应用后续再访问这些增删改的数据时，因为缓存中没有相应的数据，就会发生缓存缺失。此时，应用再从数据库中把数据读入缓存，这样后续再访问数据时，就能够直接从缓存中读取了。
接下来，我以 Tomcat 向 MySQL 中写入和删改数据为例，来给你解释一下，数据的增删改操作具体是如何进行的，如下图所示：
从图中可以看到，Tomcat 上运行的应用，无论是新增（Insert 操作）、修改（Update 操作）、还是删除（Delete 操作）数据 X，都会直接在数据库中增改删。当然，如果应用执行的是修改或删除操作，还会删除缓存的数据 X。
那么，这个过程中会不会出现数据不一致的情况呢？考虑到新增数据和删改数据的情况不一样，所以我们分开来看。
1. 新增数据
如果是新增数据，数据会直接写到数据库中，不用对缓存做任何操作，此时，缓存中本身就没有新增数据，而数据库中是最新值，这种情况符合我们刚刚所说的一致性的第 2 种情况，所以，此时，缓存和数据库的数据是一致的。
2. 删改数据
如果发生删改操作，应用既要更新数据库，也要在缓存中删除数据。这两个操作如果无法保证原子性，也就是说，要不都完成，要不都没完成，此时，就会出现数据不一致问题了。这个问题比较复杂，我们来分析一下。
我们假设应用先删除缓存，再更新数据库，如果缓存删除成功，但是数据库更新失败，那么，应用再访问数据时，缓存中没有数据，就会发生缓存缺失。然后，应用再访问数据库，但是数据库中的值为旧值，应用就访问到旧值了。
我来举个例子说明一下，可以先看看下面的图片。
应用要把数据 X 的值从 10 更新为 3，先在 Redis 缓存中删除了 X 的缓存值，但是更新数据库却失败了。如果此时有其他并发的请求访问 X，会发现 Redis 中缓存缺失，紧接着，请求就会访问数据库，读到的却是旧值 10。
你可能会问，如果我们先更新数据库，再删除缓存中的值，是不是就可以解决这个问题呢？我们再来分析下。
如果应用先完成了数据库的更新，但是，在删除缓存时失败了，那么，数据库中的值是新值，而缓存中的是旧值，这肯定是不一致的。这个时候，如果有其他的并发请求来访问数据，按照正常的缓存访问流程，就会先在缓存中查询，但此时，就会读到旧值了。
我还是借助一个例子来说明一下。
应用要把数据 X 的值从 10 更新为 3，先成功更新了数据库，然后在 Redis 缓存中删除 X 的缓存，但是这个操作却失败了，这个时候，数据库中 X 的新值为 3，Redis 中的 X 的缓存值为 10，这肯定是不一致的。如果刚好此时有其他客户端也发送请求访问 X，会先在 Redis 中查询，该客户端会发现缓存命中，但是读到的却是旧值 10。
好了，到这里，我们可以看到，在更新数据库和删除缓存值的过程中，无论这两个操作的执行顺序谁先谁后，只要有一个操作失败了，就会导致客户端读取到旧值。我画了下面这张表，总结了刚刚所说的这两种情况。
问题发生的原因我们知道了，那该怎么解决呢？

如何解决数据不一致问题？

首先，我给你介绍一种方法：重试机制。
具体来说，可以把要删除的缓存值或者是要更新的数据库值暂存到消息队列中（例如使用 Kafka 消息队列）。当应用没有能够成功地删除缓存值或者是更新数据库值时，可以从消息队列中重新读取这些值，然后再次进行删除或更新。
如果能够成功地删除或更新，我们就要把这些值从消息队列中去除，以免重复操作，此时，我们也可以保证数据库和缓存的数据一致了。否则的话，我们还需要再次进行重试。如果重试超过的一定次数，还是没有成功，我们就需要向业务层发送报错信息了。
下图显示了先更新数据库，再删除缓存值时，如果缓存删除失败，再次重试后删除成功的情况，你可以看下。
刚刚说的是在更新数据库和删除缓存值的过程中，其中一个操作失败的情况，实际上，即使这两个操作第一次执行时都没有失败，当有大量并发请求时，应用还是有可能读到不一致的数据。
同样，我们按照不同的删除和更新顺序，分成两种情况来看。在这两种情况下，我们的解决方法也有所不同。
情况一：先删除缓存，再更新数据库。
假设线程 A 删除缓存值后，还没有来得及更新数据库（比如说有网络延迟），线程 B 就开始读取数据了，那么这个时候，线程 B 会发现缓存缺失，就只能去数据库读取。这会带来两个问题：
线程 B 读取到了旧值；
线程 B 是在缓存缺失的情况下读取的数据库，所以，它还会把旧值写入缓存，这可能会导致其他线程从缓存中读到旧值。
等到线程 B 从数据库读取完数据、更新了缓存后，线程 A 才开始更新数据库，此时，缓存中的数据是旧值，而数据库中的是最新值，两者就不一致了。
我用一张表来汇总下这种情况。
这该怎么办呢？我来给你提供一种解决方案。
在线程 A 更新完数据库值以后，我们可以让它先 sleep 一小段时间，再进行一次缓存删除操作。
之所以要加上 sleep 的这段时间，就是为了让线程 B 能够先从数据库读取数据，再把缺失的数据写入缓存，然后，线程 A 再进行删除。所以，线程 A sleep 的时间，就需要大于线程 B 读取数据再写入缓存的时间。这个时间怎么确定呢？建议你在业务程序运行的时候，统计下线程读数据和写缓存的操作时间，以此为基础来进行估算。
这样一来，其它线程读取数据时，会发现缓存缺失，所以会从数据库中读取最新值。因为这个方案会在第一次删除缓存值后，延迟一段时间再次进行删除，所以我们也把它叫做“延迟双删”。
下面的这段伪代码就是“延迟双删”方案的示例，你可以看下。
redis.delKey(X)
db.update(X)
Thread.sleep(N)
redis.delKey(X)
情况二：先更新数据库值，再删除缓存值。
如果线程 A 删除了数据库中的值，但还没来得及删除缓存值，线程 B 就开始读取数据了，那么此时，线程 B 查询缓存时，发现缓存命中，就会直接从缓存中读取旧值。不过，在这种情况下，如果其他线程并发读缓存的请求不多，那么，就不会有很多请求读取到旧值。而且，线程 A 一般也会很快删除缓存值，这样一来，其他线程再次读取时，就会发生缓存缺失，进而从数据库中读取最新值。所以，这种情况对业务的影响较小。
我再画一张表，带你总结下先更新数据库、再删除缓存值的情况。
好了，到这里，我们了解到了，缓存和数据库的数据不一致一般是由两个原因导致的，我给你提供了相应的解决方案。
删除缓存值或更新数据库失败而导致数据不一致，你可以使用重试机制确保删除或更新操作成功。
在删除缓存值、更新数据库的这两步操作中，有其他线程的并发读操作，导致其他线程读取到旧值，应对方案是延迟双删。

小结

在这节课，我们学习了在使用 Redis 缓存时，最常遇见的一个问题，也就是缓存和数据库不一致的问题。针对这个问题，我们可以分成读写缓存和只读缓存两种情况进行分析。
对于读写缓存来说，如果我们采用同步写回策略，那么可以保证缓存和数据库中的数据一致。只读缓存的情况比较复杂，我总结了一张表，以便于你更加清晰地了解数据不一致的问题原因、现象和应对方案。
希望你能把我总结的这张表格放入到你的学习笔记中，时不时复习一下。
最后，我还想再多说几句。在大多数业务场景下，我们会把 Redis 作为只读缓存使用。针对只读缓存来说，我们既可以先删除缓存值再更新数据库，也可以先更新数据库再删除缓存。我的建议是，优先使用先更新数据库再删除缓存的方法，原因主要有两个：
先删除缓存值再更新数据库，有可能导致请求因缓存缺失而访问数据库，给数据库带来压力；
如果业务应用中读取数据库和写缓存的时间不好估算，那么，延迟双删中的等待时间就不好设置。
不过，当使用先更新数据库再删除缓存时，也有个地方需要注意，如果业务层要求必须读取一致的数据，那么，我们就需要在更新数据库时，先在 Redis 缓存客户端暂存并发读请求，等数据库更新完、缓存值删除后，再读取数据，从而保证数据一致性。

每课一问

按照惯例，我给你提个小问题。这节课，我提到，在只读缓存中进行数据的删改操作时，需要在缓存中删除相应的缓存值。我想请你思考一下，如果在这个过程中，我们不是删除缓存值，而是直接更新缓存的值，你觉得和删除缓存值相比，有什么好处和不足吗？
欢迎在留言区写下你的思考和答案，我们一起交流讨论。如果你觉得今天的内容对你有所帮助，也欢迎你分享给你的朋友或同事。我们下节课见。
分享给需要的人，Ta购买本课程，你将得20元
生成海报并分享

赞 70

提建议

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
24 | 替换策略：缓存满了怎么办？
下一篇
26 | 缓存异常（下）：如何解决缓存雪崩、击穿、穿透难题？
unpreview
 写留言

精选留言(89)

  • Kaito
    2020-10-14
    数据在删改操作时，如果不是删除缓存值，而是直接更新缓存的值，你觉得和删除缓存值相比，有什么好处和不足？ 这种情况相当于把Redis当做读写缓存使用，删改操作同时操作数据库和缓存。 1、先更新数据库，再更新缓存：如果更新数据库成功，但缓存更新失败，此时数据库中是最新值，但缓存中是旧值，后续的读请求会直接命中缓存，得到的是旧值。 2、先更新缓存，再更新数据库：如果更新缓存成功，但数据库更新失败，此时缓存中是最新值，数据库中是旧值，后续读请求会直接命中缓存，但得到的是最新值，短期对业务影响不大。但是，一旦缓存过期或者满容后被淘汰，读请求就会从数据库中重新加载旧值到缓存中，之后的读请求会从缓存中得到旧值，对业务产生影响。 同样地，针对这种其中一个操作可能失败的情况，也可以使用重试机制解决，把第二步操作放入到消息队列中，消费者从消息队列取出消息，再更新缓存或数据库，成功后把消息从消息队列删除，否则进行重试，以此达到数据库和缓存的最终一致。 以上是没有并发请求的情况。如果存在并发读写，也会产生不一致，分为以下4种场景。 1、先更新数据库，再更新缓存，写+读并发：线程A先更新数据库，之后线程B读取数据，此时线程B会命中缓存，读取到旧值，之后线程A更新缓存成功，后续的读请求会命中缓存得到最新值。这种场景下，线程A未更新完缓存之前，在这期间的读请求会短暂读到旧值，对业务短暂影响。 2、先更新缓存，再更新数据库，写+读并发：线程A先更新缓存成功，之后线程B读取数据，此时线程B命中缓存，读取到最新值后返回，之后线程A更新数据库成功。这种场景下，虽然线程A还未更新完数据库，数据库会与缓存存在短暂不一致，但在这之前进来的读请求都能直接命中缓存，获取到最新值，所以对业务没影响。 3、先更新数据库，再更新缓存，写+写并发：线程A和线程B同时更新同一条数据，更新数据库的顺序是先A后B，但更新缓存时顺序是先B后A，这会导致数据库和缓存的不一致。 4、先更新缓存，再更新数据库，写+写并发：与场景3类似，线程A和线程B同时更新同一条数据，更新缓存的顺序是先A后B，但是更新数据库的顺序是先B后A，这也会导致数据库和缓存的不一致。 场景1和2对业务影响较小，场景3和4会造成数据库和缓存不一致，影响较大。也就是说，在读写缓存模式下，写+读并发对业务的影响较小，而写+写并发时，会造成数据库和缓存的不一致。 针对场景3和4的解决方案是，对于写请求，需要配合分布式锁使用。写请求进来时，针对同一个资源的修改操作，先加分布式锁，这样同一时间只允许一个线程去更新数据库和缓存，没有拿到锁的线程把操作放入到队列中，延时处理。用这种方式保证多个线程操作同一资源的顺序性，以此保证一致性。 综上，使用读写缓存同时操作数据库和缓存时，因为其中一个操作失败导致不一致的问题，同样可以通过消息队列重试来解决。而在并发的场景下，读+写并发对业务没有影响或者影响较小，而写+写并发时需要配合分布式锁的使用，才能保证缓存和数据库的一致性。 另外，读写缓存模式由于会同时更新数据库和缓存，优点是，缓存中一直会有数据，如果更新操作后会立即再次访问，可以直接命中缓存，能够降低读请求对于数据库的压力（没有了只读缓存的删除缓存导致缓存缺失和再加载的过程）。缺点是，如果更新后的数据，之后很少再被访问到，会导致缓存中保留的不是最热的数据，缓存利用率不高（只读缓存中保留的都是热数据），所以读写缓存比较适合用于读写相当的业务场景。
    展开
    共 41 条评论
    325
  • Alex_QY
    2020-10-29
    延时双删根本解决不了一致性问题，高迸发场景线程A根本不知道线程B，线程C的执行开始和结束的时间。 所以sleep跟没sleep没啥区别。。。 感觉唯一的办法就是要让整个事务方法由并行变成串行。 感觉串行呢？要么借助分布式锁，要么借助MYSQL本身的update独占锁
    共 29 条评论
    109
  • ctang
    2020-10-17
    先删除缓存后更新数据库，数据库更新失败了，何来的旧值。只读缓存不是以数据库为准吗？
    共 16 条评论
    34
  • 约书亚
    2021-02-01
    完全没必要双删，双删比起先DB后删Redis，无非就是防止删除Redis操作失败。但高并发下依旧可能在第一次删期间混进来读操作。 还有基于消息队列的方案，凭啥Redis操作能会失败，DB操作会失败，消息队列就不会了呢？就算能用事务消息，难道不怕旧值覆盖新值的情况发生么？ 对于课后题，这种被称为直接缓存，除了大家说的分布式锁方案保证并发下的正确，还可以考虑基于lua实现cas，有一定性能下降但大多数场景都还能接受。
    展开
    共 6 条评论
    25
  • Reborn 2.0
    2020-11-16
    不用第二种延迟双删, 直接用先DB后删redis不就好了, 延迟双删还要麻烦一点, 感觉没有什么优点啊
    共 3 条评论
    9
  • 不诉离殇
    2020-10-19
    老师分析问题的思路很赞，但是我对于结论有一个很大的疑问，按照分析思路 ，既然对于读写缓存同步写回策略可以采用（分布式）事务来保证原子性，那么只读缓存的更新数据库和删除缓存的操作为什么不能采用事务来保证原子性？二者的思路差异在哪里？
    共 4 条评论
    8
  • 范闲
    2020-10-20
    更新步骤: 1.先更新缓存，再更新数据库 2.先更新数据库，再更新缓存 并发: 1.读+写 2.写+写 3.读+读 在并发情况下，3是肯定没有影响的。1和2肯定会对数据一致性有影响。这个时候可以利用分布式锁来处理。同一时刻一个key只有一把锁持有。
    展开
    8
  • williamcai
    2020-10-16
    老师你好，用事务保证数据库和redis一致，不可行呀
    共 7 条评论
    6
  • 与路同飞
    2020-10-14
    如果业务层要求必须读取一致的数据，那么，我们就需要在更新数据库时，先在 Redis 缓存客户端暂存并发读请求，等数据库更新完，再读取数据，从而保证数据一致性。这个redis客户端暂存并发读请求咋弄
    共 10 条评论
    6
  • wjunt928
    2022-03-16
    看了一堆评论，其实会发现讨论的时候，说着说着大家关于一致性的概念理解就发生变化了； 有时说的一致性指的是强一致性，有时说的一致性又是最终一致性，所以大家互觉得对方有问题； (1)只要缓存和数据库更新有先后，就一定达不到强一致性(达到数据库和缓存在同一瞬间都更新的效果)； (2)即便使用最终一致性，也有方法实现： a.尽量降低出现长时间才能达到最终一致性的概率； b.尽量减少达到最终一致性的时间； 所以才会有人认为延迟双删解决不了一致性，因为这个一致性指的是强一致性； 而老师专栏说延迟双删可以保证一致性，也仅仅是指"减少数据库和缓存达到最终一致的时间"；
    展开
    共 2 条评论
    6
  • Sancho
    2022-05-08
    我和大家一样觉得“延时双删”方案不行。 在极客时间另一位老师傅的课学到一个方案，总结下来是这样的： 1.读操作时，先读缓存，缓存Miss，读DB。此时用SETNX写缓存，只有缓存中还没有时再会成功，操作缓存的优先级比较低； 2.写操作时，先删除缓存，再写DB成功，最后用SET写缓存； 3.订阅DB变更，用DB最终数据，SETEX操作刷新缓存。
    展开
    共 3 条评论
    4
  • 何磊
    2021-05-09
    双删太过于了。互联网场景基本用先更新db，再删除redis，基本可以保证数据的一致性。 理论上也存在并发导致的不一致问题，但是概率极低。至今我都没有遇到过
    共 2 条评论
    4
  • liudu_ec
    2020-10-18
    蒋老师，问个问题，我现在是用缓存失效+ binlog 订阅更新缓存的，日常使用场景中，查询请求先查缓存，如果没有 就查数据库，数据库没有就会构建一条空缓存来保护数据库， 还有一种场景是使用pipeline批量查询缓存，如果存在某个key不存在的情况，应该怎么优雅处理？
    共 1 条评论
    4
  • Mine
    2021-02-04
    给缓存设置过期时间，即使更新完数据库数据之后，删除缓存失败，缓存在过期时间到了失效之后重新拉取最新的数据保证最终的一致性。
    2
  • Geek_1e8830
    2021-02-02
    先删除缓存，在更新数据库失败，然后读取到旧值这不应该是正常的吗？既然数据库都更新失败了，那理所当然接下来获取到的肯定是旧值赛，没问题个人觉得这里。
    共 1 条评论
    2
  • 石小
    2020-11-17
    老师好，给缓存做持久化，更新数据时只更新到缓存，之后由专门的进城进行刷到数据库；读取数据时也是从缓存读，读不到再从数据库读。这种方式有什么问题吗？
    2
  • 慎独明强
    2020-10-17
    总结一下:1.先删除缓存再更新或删除数据库，如果删除数据库失败，其他线程读取到数据库的旧值，我觉得不应该叫旧值，都没有更新成功，数据库事务应该要回滚，这次业务应该算失败。对业务没有影响。 2.先删除缓存再更新数据库的并发场景，需要延迟双删。延迟这个时间不好控制，也会出现早删除，也会造成数据不一致。 3.先更新数据库，再删除缓存，需要保持原子性，可以采用队列来保持最终一致性。 4.先更新数据库，后删除缓存，会出现并发读，数据库已经更新但缓存更新，可以采用将读写操作写到队列，队列来保证操作的有序性，需要考虑性能。 5.对于有并发读写请求，有两个思路，分布式锁来限制并发。或者采用redis读写，mysql只做备份，保持最终一致性。这需要考虑redis的高可用。
    展开
    2
  • ub8
    2021-09-10
    延迟双删我擦笑死我了这个方案
    共 1 条评论
    1
  • 吃饭睡觉打酱油
    2021-04-27
    先更新数据库，再删除缓存这种，如果是缓存正好过期，来了一个读请求已经读到数据了，但是还没写入缓存，此时再来个并发更新数据库的操作，我们的写入缓存操作又在删除缓存之后，那最终，缓存的数据不就是旧数据了么？
    共 2 条评论
    1
  • escray
    2021-03-29
    我觉得专栏先定义了缓存数据一致性，这个是很有必要的，一种是缓存中有数据，且和数据库中一样；一种是缓存中没数据，数据库中是最新值。 在学习专栏之前，感觉只读缓存的数据一致性要好于读写缓存，而两种缓存模式如果想要保持一致性的话，都需要采用原子性的事务处理。 但是按照专栏的说法，其实是说读写缓存的同步写回策略可以保证缓存和数据库中的数据一致。 其实缓存一致性问题和其他的分布式一致性问题从本质上来看似乎是一样的。 对于课后题，只读缓存数据删改操作，如果在缓存中不是删除，而是更新，那么首先更新应该比删除慢，而且更新之后的数据其实不一定会在短时间内用得到。可能有个别的业务场景，比较适合缓存更新，但是更普遍的应该还是缓存删除。
    展开
    1