redis缓存主要问题及解决思路附思维导图_先查本地缓存，再查redis

redis

缓存主要问题及解决思路

缓存穿透

• 介绍

  • 对于系统A，假设一秒 5000 个请求，结果其中 4000 个请求是黑客发出的恶意攻击。黑客发出的那 4000 个攻击，缓存中查不到，每次你去数据库里查，也查不到。那么这些查不到的请求就会将数据库打死，缓存失效。

    举个栗子。数据库 id 是从 1 开始的，结果黑客发过来的请求 id 全部都是负数。这样的话，缓存中不会有，请求每次都“视缓存于无物”，直接查询数据库。这种恶意攻击场景的缓存穿透就会直接把数据库给打死。

• 导致的问题

  • 一个一定不存在缓存及查询不到的数据，由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。

• 解决

  • 最常见的则是采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被 这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。
  • 解决方式很简单，每次系统 A 从数据库中只要没查到，就写一个空值到缓存里去，比如 set -999 UNKNOWN。然后设置一个过期时间，但它的过期时间会很短，最长不超过五分钟。这样的话，下次有相同的 key 来访问的时候，在缓存失效之前，都可以直接从缓存中取数据。

缓存击穿

• 介绍

  • 缓存击穿，就是说某个 key 非常热点，访问非常频繁，处于集中式高并发访问的情况，当这个 key 在失效的瞬间，大量的请求就击穿了缓存，直接请求数据库，就像是在一道屏障上凿开了一个洞。

• 解决

  • 可以将热点数据设置为永远不过期；
  • 或者基于 redis or zookeeper 实现互斥锁，等待第一个请求构建完缓存之后，再释放锁，进而其它请求才能通过该 key 访问数据。

缓存雪崩

• 介绍

  对于系统 A，假设每天高峰期每秒 5000 个请求，本来缓存在高峰期可以扛住每秒 4000 个请求，但是缓存机器意外发生了全盘宕机。缓存挂了，此时 1 秒 5000 个请求全部落数据库，数据库必然扛不住，它会报一下警，然后就挂了。此时，如果没有采用什么特别的方案来处理这个故障，DBA 很着急，重启数据库，但是数据库立马又被新的流量给打死了。
  这就是缓存雪崩。

  • 正常情况下由缓存来处理高峰期的大量请求，但是在缓存服务器意外宕机，重启或者出现其他问题，不能处理这些请求，这些请求就会直接全部落在数据库上，数据库必然扛不住，就会报警，然后重启，重启之后再次被大量请求给打死了，也就是数据库hang住了。

• 按阶段解决

  • 事前

    • redis 高可用，主从+哨兵，redis cluster，避免全盘崩溃。

  • 事中

    • 本地 ehcache 缓存（二级缓存） + hystrix 限流&降级，避免 MySQL 被打死。

  • 事后

    • redis 持久化，一旦重启，自动从磁盘上加载数据，快速恢复缓存数据。

• 按方法解决

  • 加锁或者队列

    • 大多数系统设计者考虑用加锁或者队列的方式保证来保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存储系统上。

  • 将缓存失效时间分散开

    • 还有一个简单方案就时讲缓存失效时间分散开，比如我们可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。

  • 设置过期标志更新缓存

    • 缓存标记：记录缓存数据是否过期，如果过期会触发通知另外的线程在后台去更新实际key的缓存；
    • 缓存数据：它的过期时间比缓存标记的时间延长1倍，例：标记缓存时间30分钟，数据缓存设置为60分钟。这样，当缓存标记key过期后，实际缓存还能把旧数据返回给调用端，直到另外的线程在后台更新完成后，才会返回新缓存。

  • 还有一种被称为“二级缓存”的解决方法（本地 ehcache 缓存）

• 原理

  • 用户发送一个请求，系统 A 收到请求后，先查本地 ehcache 缓存，如果没查到再查 redis。如果 ehcache 和 redis 都没有，再查数据库，将数据库中的结果，写入 ehcache 和 redis 中。
  • 限流组件，可以设置每秒的请求，有多少能通过组件，剩余的未通过的请求，怎么办？走降级！可以返回一些默认的值，或者友情提示，或者空白的值。

• 好处

  • 数据库绝对不会死，限流组件确保了每秒只有多少个请求能通过。
  • 只要数据库不死，就是说，对用户来说，2/5 的请求都是可以被处理的。
  • 只要有 2/5 的请求可以被处理，就意味着你的系统没死，对用户来说，可能就是点击几次刷不出来页面，但是多点几次，就可以刷出来一次。

缓存其他问题

缓存满了

• 采用LRU策略处理溢出

数据丢失

• Redis的RDB和AOF持久化策略来保证一定情况下的数据安全

链接: 思维导图源文件 提取码: ybqh
链接: https://pan.baidu.com/s/16wRs6qsJBubAD0ytvEH8aQ 提取码: ybqh 复制这段内容后打开百度网盘手机App，操作更方便哦