前言

Redis 缓存的使用，极大的提升了应用程序的性能和效率，特别是数据查询方面。但同时，它也带来了一些问题。其中，最要害的问题，就是数据的一致性问题，从严格意义上讲，这个问题无解。如果对数据的一致性要求很高，那么就不能使用缓存。
另外的一些典型问题就是，缓存穿透、缓存雪崩和缓存击穿，这些问题都影响着服务的高可用性。目前，业界也都有比较流行的解决方案。

这里要特别感谢b站的up主：狂神说，在我Redis的学习中，很多内容笔记都是从这位大佬那里找来的，感兴趣的可以去看他的视频或者关注他的微信公众号“狂神说“”

一、缓存穿透

1. 概念

key对应的数据在数据源并不存在，每次针对此key的请求从缓存获取不到，请求都会压到数据源，从而可能压垮数据源。比如用一个不存在的用户id获取用户信息，不论缓存还是数据库都没有，若黑客利用此漏洞进行攻击可能压垮数据库。

2. 解决方案

  • 布隆过滤器
    • 布隆过滤器是一种数据结构，对所有可能查询的数据以 hash 形式存储到一个足够大的bitmaps中，在控制层先进行校验，一个一定不存在的数据会被 这个bitmaps拦截掉，从而避免了对底层存储系统的查询压力（布隆过滤器可以用于检索一个元素是否在一个集合中，它的优点是空间效率和查询时间都远远超过一般的算法，缺点是有一定的误识别率和删除困难）。
  • 缓存空对象
    • 当存储层不命中后，即使返回的空对象也将其缓存起来，同时设置一个过期时间，之后再访问这个数据将会从缓存中获取，保护了后端数据源。
    • 缺点：
      • 如果空值能够被缓存起来，这就意味着缓存需要更多的空间存储更多的键，因为这当中可能会有很多的空值的键；
      • 即使对空值设置了过期时间，还是会存在缓存层和存储层的数据会有一段时间窗口的不一致，这对于需要保持一致性的业务会有影响。
  • 设置可访问的白名单
    • 使用 bitmaps 类型定义一个可以访问的名单，名单 id 作为 bitmaps 的偏移量，每次访问和 bitmap 里面的 id 进行比较，如果访问 id 不在 bitmaps 里面，进行拦截，不允许访问
  • 进行实时监控
    • 当发现 Redis 的命中率开始急速降低，需要排查访问对象和访问的数据，和运维人员配合，可以设置黑名单限制服务

二、缓存击穿

1. 概念

缓存击穿，是指一个 key 非常热点，在不停的承担数据的并发，大并发集中对这一个点进行访问，当这个 key 在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，就像在一个屏障上凿开了一个洞。
当某个 key 在过期的瞬间，有大量的请求并发访问，这类数据一般是热点数据，由于缓存过期，会同时访问数据库来查询最新数据，并且回写缓存，会导使数据库瞬间压力过大，这个时候大并发的请求可能会瞬间把后端 DB 压垮。

2. 解决方案

  • 预先设置热门数据

    • 预先设置热门数据：在 redis 高峰访问之前，把一些热门数据提前存入到 redis 里面，加大这些热门数据 key 的时长

  • 实时调整

    • 现场监控哪些数据热门，实时调整key的过期时长

  • 使用锁

    • 就是在缓存失效的时候（判断拿出来的值为空），不是立即去 load db
    • 先使用缓存工具的某些带成功操作返回值的操作（比如 Redis 的 SETNX ）去 set 一个 mutex key
    • 当操作返回成功时，再进行 load db 的操作，并回设缓存,最后删除 mutex key
    • 当操作返回失败，证明有线程在 load db，当前线程睡眠一段时间再重试整个 get 缓存的方法

三、缓存雪崩

1. 概念

缓存雪崩是指在某个时间段，缓存集中过期失效，key 对应的数据存在，但在 redis 中过期，此时若有大量并发请求过来，这些请求发现缓存过期一般都会从后端 DB 加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端 DB 压垮。
其实集中过期，倒不是很致命，比较致命的缓存雪崩，是缓存服务器某个节点宕机或断网。因为自然形成的缓存雪崩，一定是在某个时间段集中创建缓存，这个时候，数据库也是可以顶住压力的。无非就是对数据库产生周期性的压力而已。而缓存服务器节点的宕机，对数据库服务器造成的压力是不可预知的，很有可能瞬间就把数据库压垮。

缓存雪崩与缓存击穿的区别在于这里针对很多 key 缓存，前者则是某一个 key

正常访问：

缓存失效瞬间：

2. 解决方案

  • redis高可用
    • 增加 redis 集群规模
  • 构建多级缓存架构
    • nginx 缓存 + redis 缓存 + 其他缓存（ehcache等）
  • 使用锁或队列
    • 用加锁或者队列的方式保证来保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存储系统上（不适用高并发情况）
  • 设置过期标志更新缓存
    • 记录缓存数据是否过期（设置提前量），如果过期会触发通知另外的线程在后台去更新实际key的缓存
  • 将缓存失效时间分散开
    • 比如我们可以在原有的失效时间基础上增加一个随机值，比如 1-5 分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件