Redis缓存穿透/击穿/雪崩以及数据一致性的解决方案

愚人钊呀

已于 2023-12-06 10:01:23 修改

阅读量111

点赞数

分类专栏： Redis 文章标签： 1024程序员节

于 2023-10-24 10:27:07 首次发布

本文链接：https://blog.csdn.net/qq_44114187/article/details/134005656

版权

Redis 专栏收录该内容

6 篇文章 0 订阅

订阅专栏

缓存穿透

缓存穿透是指查询缓存和数据库中都不存在的数据，导致所有的查询压力全部给到了数据库。

解决方案一：缓存空对象

针对缓存穿透问题缓存空对象可以有效避免所产生的影响，当查询一条不存在的数据时，在缓存中存储一个空对象并设置一个过期时间(设置过期时间是为了避免出现数据库中存在了数据但是缓存中仍然是空数据现象)，这样可以避免所有请求全部查询数据库的情况。

解决方案二：布隆过滤器

缓存空对象的缺点在于无论数据存不存在都需要查询一次数据库，并且redis中存储了大量的空数据，这个时候可以采用布隆过滤器来解决。布隆过滤器可以简单的理解为由一个很长的二进制数组结合n个hash算法计算出n个数组下标，将这些数据下标置为1。在查找数据时，再次通过n个hash算法计算出数组下标，如果这些下标的值为1，表示该值可能存在(存在hash冲突的原因)，如果为0，则表示该值一定不存在。
--------------------------------------------------------------------

缓存击穿

缓存击穿是指访问某个热点数据时，缓存中并不存在该数据或者缓存过期了，这个时候全部的请求压力给到了数据库。

解决方案一：热点数据不设置过期时间

热点数据不设置过期时间，当后台更新热点数据数需要同步更新缓存中的数据，这种解决方式适用于不严格要求缓存一致性的场景。

解决方案二：使用互斥锁

如果是单机部署的环境下可以使用synchronized或lock来处理，保证同时只能有一个线程来查询数据库，其他线程可以等待数据缓存成功后在被唤醒，从而直接查询缓存即可。如果是分布式部署，可以采用分布式锁来实现互斥。

--------------------------------------------------------------------

缓存雪崩

缓存雪崩是指对热点数据设置了相同的过期时间，在同一时间这些热点数据key大批量发生过期，请求全部转发到数据库，从而导致数据库压力骤增，甚至宕机。与缓存击穿不同的是，缓存击穿是单个热点数据过期，而缓存雪崩是大批量热点数据过期。

解决方案一：设置随机的过期时间

将key的过期时间后面加上一个随机数,这个随机数值的范围可以根据自己的业务情况自行设定，这样可以让key均匀的失效，避免大批量的同时失效。

解决方案二：不设置过期时间

不设置过期时间时，需要注意的是，在更新数据库数据时，同时也需要更新缓存数据，否则数据会出现不一致的情况。这种方式比较适用于不严格要求缓存一致性的场景。

解决方案三：搭建高可用集群

缓存服务故障时，也会触发缓存雪崩，为了避免因服务故障而发生的雪崩，推荐使用高可用的服务集群，这样即使发生故障，也可以进行故障转移。集群相关的在之前也有介绍过Redis高可用架构搭建到原理分析

--------------------------------------------------------------------

数据一致性

通常情况下，使用缓存的直接目的是为了提高系统的查询效率，减轻数据库的压力。一般情况下使用缓存是下面这几步骤：

查询缓存，数据是否存在
如果数据存在，直接返回
如果数据不存在，再查询数据库
如果数据库中数据存在，那么将该数据存入缓存并返回。如果不存在，返回空。

这么搞好像看上去并没有啥问题，那么会有一个细节问题：当一条数据存入缓存后，立刻又被修改了，那么这个时候缓存该如何更新呢。不更新肯定不行，这样导致了缓存中的数据与数据库中的数据不一致。一般情况下对于缓存更新有下面这几种情况：

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

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

先更新缓存，再更新数据库这种情况下，如果业务执行正常，不出现网络等问题，这么操作不会有啥问题，两边都可以更新成功。但是，如果缓存更新成功了，但是当更新数据库时或者在更新数据库之前出现了异常，导致数据库无法更新。这种情况下，缓存中的数据变成了一条实际不存在的假数据。

先调用更新的接口，在调用查询的接口，结果发现查询的接口返回的并不是数据库中的实际数据，这个时候就造成了缓存与数据库数据不一致的情况。

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

先更新数据库，再更新缓存和先更新缓存，再更新数据库的情况基本一致，如果失败，会导致数据库中是最新的数据，缓存中是旧数据。还有一种极端情况，在高并发情况下容易出现数据覆盖的现象：A线程更新完数据库后，在要执行更新缓存的操作时，线程被阻塞了，这个时候线程B更新了数据库并成功更新了缓存，当B执行完成后线程A继续向下执行，那么最终线程B的数据会被覆盖。

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

先删除缓存，再更新数据库这种情况，如果并发量不大用起来不会有啥问题。但是在并发场景下会有这样的问题：线程A在删除缓存后，在写入数据库前发生了阻塞。这时线程B查询了这条数据，发现缓存中不存在，继而向数据库发起查询请求，并将查询结果缓存到了redis。当线程B执行完成后，线程A继续向下执行更新了数据库，那么这时缓存中的数据为旧数据，与数据库中的值不一致。

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

先更新数据库，再删除缓存也并不是绝对安全的，在高并发场景下，如果线程A查询一条在缓存中不存在的数据(这条数据有可能过期被删除了)，查询数据库后在要将查询结果缓存到redis时发生了阻塞。这个时候线程B发起了更新请求，先更新了数据库，再次删除了缓存。当线程B执行成功后，线程A继续向下执行，将查询结果缓存到了redis中，那么此时缓存中的数据与数据库中的数据发生了不一致。