redis——缓存雪崩、缓存穿透和缓存击穿

最新推荐文章于 2024-04-15 22:05:45 发布

lans_g

最新推荐文章于 2024-04-15 22:05:45 发布

阅读量636

点赞数

分类专栏： redis 文章标签：缓存 redis java

本文链接：https://blog.csdn.net/lans_g/article/details/124633549

版权

redis 专栏收录该内容

14 篇文章 2 订阅

订阅专栏

前言

当用户访问数据时，如果用户的请求直接访问数据库的话，数量一多数据库就很容易奔溃，所以为了避免这个问题，会用 Redis 作为缓存层。 Redis 是内存数据库，相当于数据缓存在内存，内存的读写速度比硬盘快好几个数量级，这样大大提高了系统性能。

但是引入了缓存层，就会有缓存异常的三个问题，分别是缓存雪崩、缓存击穿、缓存穿透。

一、缓存雪崩

通常我们为了保证缓存中的数据与数据库中的数据一致性，会给 Redis 里的数据设置过期时间，当缓存数据过期后，如果用户访问的数据不在缓存里，业务系统需要重新生成缓存，因此就会访问数据库，并将数据更新到 Redis 里。

当大量缓存数据在同一时间过期（失效）或者 Redis 故障宕机时，如果此时有大量的用户请求，都无法在 Redis 中处理，于是全部请求都直接访问数据库，从而导致数据库的压力骤增，严重的会造成数据库宕机，从而形成一系列连锁反应，造成整个系统崩溃，这就是缓存雪崩的问题。

如何解决这个问题呢？针对不同的原因有不同的策略。

1.大量数据同时过期

均匀设置过期时间

当给缓存数据设置过期时间时，应该避免将大量的数据设置成同一个过期时间，这样就保证数据不会在同一时间过期。
互斥锁

当业务线程在处理用户请求时，如果发现访问的数据不在 Redis 里，就加个互斥锁，保证同一时间内只有一个请求来构建缓存（从数据库读取数据，再将数据更新到 Redis 里），当缓存构建完成后，再释放锁。未能获取互斥锁的请求，要么等待锁释放后重新读取缓存，要么就返回空值或者默认值。

实现互斥锁的时候，最好设置超时时间，不然第一个请求拿到了锁，然后这个请求发生了某种意外而一直阻塞，一直不释放锁，这时其他请求也一直拿不到锁，整个系统就会出现无响应的现象。
后台更新缓存

业务线程不再负责更新缓存，缓存也不设置有效期，而是让缓存“永久有效”，并将更新缓存的工作交由后台线程定时更新。

事实上，缓存数据不设置有效期，并不是意味着数据一直能在内存里，因为当系统内存紧张的时候，有些缓存数据会被“淘汰”，而在缓存被“淘汰”到下一次后台定时更新缓存的这段时间内，业务线程读取缓存失败就返回空值，业务的视角就以为是数据丢失了。

为了解决这个问题，在业务线程发现缓存数据失效后（缓存数据被淘汰），可以通过消息队列发送一条消息通知后台线程更新缓存，后台线程收到消息后，在更新缓存前可以判断缓存是否存在，存在就不执行更新缓存操作；不存在就读取数据库数据，并将数据加载到缓存。在业务刚上线的时候，我们最好提前把数据缓起来，而不是等待用户访问才来触发缓存构建，这就是所谓的缓存预热。

2.redis故障宕机

服务熔断或请求限流机制

服务熔断机制，就是暂停业务应用对缓存服务的访问，直接返回错误，不用再继续访问数据库，然后等到 Redis 恢复正常后，再允许业务应用访问缓存服务。但是这样会导致其他业务也无法正常工作，所以一般会采取请求限流机制。

限流是只将少部分请求发送到数据库进行处理，再多的请求可以通过降级，返回一些默认值或者空值，等到 Redis 恢复正常并把缓存预热完后，再解除请求限流的机制。
构建 Redis 缓存高可靠集群

通过主从节点的方式构建 Redis 缓存高可靠集群。如果 Redis 缓存的主节点故障宕机，从节点可以切换成为主节点，继续提供缓存服务。