9. Redis 缓存穿透、缓存击穿、缓存雪崩
文章目录
-
- 9. Redis 缓存穿透、缓存击穿、缓存雪崩
-
- 9.1 缓存穿透
- 9.2 缓存击穿
- 9.3 缓存雪崩
- 9.4 缓存污染
- 总结
9. Redis 缓存穿透、缓存击穿、缓存雪崩
参考地址：
https://blog.csdn.net/w15558056319/article/details/121649661
https://xiaolincoding.com/redis/cluster/cache_problem.html#%E6%80%BB%E7%BB%93
- 前言
Redis是非关系型数据库，数据都存储在内存中，既可以当做数据库存储数据，也能作为日常缓存使用，本文主要探讨Redis作为缓存，在实践中可能会有哪些问题？比如一致性, 穿击, 穿透, 雪崩, 污染等。
缓存的使用，极大的提升了应用程序的性能和效率，特别是数据查询方面，也大大缓解了数据库访问压力，但同时，它也带来了一些问题。其中，最要害的问题，就是数据的一致性问题，从严格意义上讲，这个问题无解。如果对数据的一致性要求很高，那么就不能使用缓存。
另外一些典型的问题就是，
缓存穿透、缓存击穿和缓存雪崩。目前业界也都有较流行的解决方案
9.1 缓存穿透
简单理解：没有数据
概念：用户请求缓存和数据库中都没有的数据。
当用户访问的数据，既不在缓存中，也不在数据库中，导致请求在访问缓存时，发现缓存缺失，再去访问数据库时，发现数据库中也没有要访问的数据，没办法构建缓存数据，来服务后续的请求。那么当有大量这样的请求到来时，数据库的压力骤增，这就是缓存穿透的问题。
缓存穿透的发生一般有这两种情况：
- 业务误操作，缓存中的数据和数据库中的数据都被误删除了，所以导致缓存和数据库中都没有数据；
- 黑客恶意攻击，故意大量访问某些读取不存在数据的业务；
▶️ **举例说明：**查询 “ id= -1 ” 或 id特别大不存在的数据。可能发生黑客利用不存在的key频繁攻击。
常见的三种解决方案
-
非法请求的限制
如用户参数校验，id<=0的直接拦截；判断出是恶意请求就直接返回错误，避免进一步访问缓存和数据库。
-
缓存空值或者默认值
如果是缓存和数据库都查不到的情况下，可以把key保存到Redis中，设置value=“null”，过期时间可设置短点(如30秒)。防止用户反复用同一个key暴力攻击， 需注意：如果Key是随机的，那存进Redis也只是浪费内存
- 布隆过滤器（hash结构）
将数据库中的所有key都存储在布隆过滤器中，查询Redis前先去布隆过滤器查询 key 是否存在，不存在就直接返回，避免了对底层存储系统的查询压力
9.2 缓存击穿
简单理解：有数据，单个数据缓存失效；大量数据访问同一个失效缓存
举例说明：
假如微博缓存中的某个热点数据过期了，此时大量的请求访问了该热点数据，就无法从缓存中读取，直接访问数据库，数据库很容易就被高并发的请求冲垮
解决方案：
- 设置热点数据永远不过期，由后台异步更新缓存；或者在热点数据准备要过期前，提前通知后台线程更新缓存以及重新设置过期时间；
- 接口限流与熔断，降级。重要的接口一定要做好限流策略，防止用户恶意刷接口，同时要降级准备，当接口中的某些 服务 不可用时候，进行熔断，失败快速返回机制。
- 互斥锁方案，保证同一时间只有一个业务线程更新缓存，未能获取互斥锁的请求，要么等待锁释放后重新读取缓存，要么就返回空值或者默认值
9.3 缓存雪崩
简单理解：有数据，但是大量的缓存失效；同时大量的并发查询不同数据
通常我们为了保证缓存中的数据与数据库中的数据一致性，会给 Redis 里的数据设置过期时间，当缓存数据过期后，用户访问的数据如果不在缓存里，业务系统需要重新生成缓存，因此就会访问数据库，并将数据更新到 Redis 里，这样后续请求都可以直接命中缓存。
当大量缓存数据在同一时间过期（失效）或者 Redis 故障宕机时，如果此时有大量的用户请求，都无法在 Redis 中处理，于是全部请求都直接访问数据库，从而导致数据库的压力骤增，严重的会造成数据库宕机，从而形成一系列连锁反应，造成整个系统崩溃，这就是缓存雪崩
由上可以看到，发生缓存雪崩的主要原因一般有两个
- 大量数据同时过期
- Redis 宕机
不同的诱因，应对策略也是不同的
❓ 大量数据同时过期
解决方案
1️⃣ 均匀设置过期时间
如果要给缓存数据设置过期时间，应该避免将大量的数据设置成同一个过期时间。我们可以在对缓存数据设置过期时间时，给这些数据的过期时间加上一个随机数，这样就保证数据不会在同一时间过期。
2️⃣ 互斥锁
当业务线程在处理用户请求时，如果发现访问的数据不在 Redis 里，就加个互斥锁，保证同一时间内只有一个请求来构建缓存（从数据库读取数据，再将数据更新到 Redis 里），当缓存构建完成后，再释放锁。未能获取互斥锁的请求，要么等待锁释放后重新读取缓存，要么就返回空值或者默认值。
实现互斥锁的时候，最好设置超时时间，不然第一个请求拿到了锁，然后这个请求发生了某种意外而一直阻塞，一直不释放锁，这时其他请求也一直拿不到锁，整个系统就会出现无响应的现象。
3️⃣ 双 key 策略
我们对缓存数据可以使用两个 key，一个是主 key，会设置过期时间，一个是备 key，不会设置过期，它们只是 key 不一样，但是 value 值是一样的，相当于给缓存数据做了个副本。
当业务线程访问不到「主 key 」的缓存数据时，就直接返回「备 key 」的缓存数据，然后在更新缓存的时候，同时更新「主 key 」和「备 key 」的数据。
4️⃣ 后台更新缓存
业务线程不再负责更新缓存，缓存也不设置有效期，而是让缓存“永久有效”，并将更新缓存的工作交由后台线程定时更新。
事实上，缓存数据不设置有效期，并不是意味着数据一直能在内存里，因为当系统内存紧张的时候，有些缓存数据会被“淘汰”，而在缓存被“淘汰”到下一次后台定时更新缓存的这段时间内，业务线程读取缓存失败就返回空值，业务的视角就以为是数据丢失了。
解决上面的问题的方式有两种。
第一种方式，后台线程不仅负责定时更新缓存，而且也负责频繁地检测缓存是否有效，检测到缓存失效了，原因可能是系统紧张而被淘汰的，于是就要马上从数据库读取数据，并更新到缓存。
这种方式的检测时间间隔不能太长，太长也导致用户获取的数据是一个空值而不是真正的数据，所以检测的间隔最好是毫秒级的，但是总归是有个间隔时间，用户体验一般。
第二种方式，在业务线程发现缓存数据失效后（缓存数据被淘汰），通过消息队列发送一条消息通知后台线程更新缓存，后台线程收到消息后，在更新缓存前可以判断缓存是否存在，存在就不执行更新缓存操作；不存在就读取数据库数据，并将数据加载到缓存。这种方式相比第一种方式缓存的更新会更及时，用户体验也比较好。
在业务刚上线的时候，我们最好提前把数据缓起来，而不是等待用户访问才来触发缓存构建，这就是所谓的缓存预热，后台更新缓存的机制刚好也适合干这个事情。
❓ Redis 宕机
解决方案
1️⃣ 服务熔断或请求限流机制
因为 Redis 故障宕机而导致缓存雪崩问题时，我们可以启动服务熔断机制，暂停业务应用对缓存服务的访问，直接返回错误，不用再继续访问数据库，从而降低对数据库的访问压力，保证数据库系统的正常运行，然后等到 Redis 恢复正常后，再允许业务应用访问缓存服务。
服务熔断机制是保护数据库的正常允许，但是暂停了业务应用访问缓存服系统，全部业务都无法正常工作
为了减少对业务的影响，我们可以启用请求限流机制，只将少部分请求发送到数据库进行处理，再多的请求就在入口直接拒绝服务，等到 Redis 恢复正常并把缓存预热完后，再解除请求限流的机制。
2️⃣ 构建 Redis 缓存高可用集群
服务熔断或请求限流机制是缓存雪崩发生后的应对方案，我们最好通过主从节点的方式构建 Redis 缓存高可靠集群。
如果 Redis 缓存的主节点故障宕机，从节点可以切换成为主节点，继续提供缓存服务，避免了由于 Redis 故障宕机而导致的缓存雪崩问题。
9.4 缓存污染
指的是对部分访问一次 或 少次访问的数据，不会再访问了，这部分数据依然存留在缓存中，占用内存空间。
缓存污染会随着数据的持续增加而逐渐显露。随着服务的不断运行，久而久之，缓存中会存在大量冷门数据（即很少访问）。直到空间满了，再往缓存里写数据时产生额外开销，影响Redis性能。比如写时的判断淘汰策略，根据淘汰策略去选择要淘汰的数据，然后进行删除操作。
redis.conf 配置文件中可设置 maxmemory-policy 参数，主要针对 Redis 的超过 maxmemory 设置的容量后，对数据的处理策略。
总结
- 事前：Redis 高可用，主从+哨兵，Redis cluster，避免全盘崩溃。
- 事中：本地 ehcache 缓存 + Hystrix 限流+降级，避免 MySQL 被宕机。
- 事后：Redis 持久化 RDB+AOF，一旦重启，自动从磁盘上加载数据，快速恢复缓存数据。
➡️ 限流+降级
限流组件，可以设置每秒的请求，有多少能通过组件，剩余的未通过的请求，采用 降级！返回提示：系统忙碌中，或者空白页面。对用户来说，对加载不出来的页面可能就是多刷新几次。
比如，某某微博热搜，有的人直接进了，有的人就显示空白页面，多刷新几次后也能出来，就是降级原理，牺牲部分用户体验换取服务器安全！