缓存穿透、缓存雪崩、hot key

发表于 | 分类于 | 阅读次数:

在做排行榜的时候，对缓存的更新频率产生了一定的疑问，在网上也看了不少博客对这方面的介绍，这里对看到的知识做个总结。

缓存穿透

缓存穿透是指查询一个一定不存在的数据，由于缓存是不命中时要查询数据库，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。在流量大时，可能DB就挂掉了，要是有人利用不存在的key频繁攻击我们的应用，这就是漏洞

解决方法

1. 空值缓存

这是一个比较简单暴力的方法，如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。

缺点

  • 空值做了缓存，意味着缓存层中存了更多的键，需要更多的内存空间 ( 如果是攻击，问题更严重 )，比较有效的方法是针对这类数据设置一个较短的过期时间，让其自动剔除。

  • 缓存层和存储层的数据会有一段时间窗口的不一致，可能会对业务有一定影响。例如过期时间设置为 5 分钟，如果此时存储层添加了这个数据，那此段时间就会出现缓存层和存储层数据的不一致，此时可以利用消息系统或者其他方式清除掉缓存层中的空对象。

2. Bloom Filter

Bloom Filter是一个占用空间很小、效率很高的随机数据结构，它由一个bit数组和一组Hash算法构成。可用于判断一个元素是否在一个集合中，查询效率很高（1-N，最优能逼近于1）。
在很多场景下，我们都需要一个能迅速判断一个元素是否在一个集合中。譬如：

  1. 网页爬虫对URL的去重，避免爬取相同的URL地址；
  2. 反垃圾邮件，从数十亿个垃圾邮件列表中判断某邮箱是否垃圾邮箱（同理，垃圾短信）；
  3. 缓存击穿，将已存在的缓存放到布隆中，当黑客访问不存在的缓存时迅速返回避免缓存及DB挂掉。

原理

初始化状态是一个全为0的bit数组

为了表达存储N个元素的集合，使用K个独立的函数来进行哈希运算。x1，x2……xk为k个哈希算法。
如果集合元素有N1，N2……NN，N1经过x1运算后得到的结果映射的位置标1，经过x2运算后结果映射也标1，已经为1的报错1不变。经过k次散列后，对N1的散列完成。
依次对N2，NN等所有数据进行散列，最终得到一个部分为1，部分位为0的字节数组。当然了，这个字节数组会比较长，不然散列效果不好。

那么怎么判断一个外来的元素是否已经在集合里呢，譬如已经散列了10亿个垃圾邮箱，现在来了一个邮箱，怎么判断它是否在这10亿里面呢？
很简单，就拿这个新来的也依次经历x1，x2……xk个哈希算法即可。
在任何一个哈希算法譬如到x2时，得到的映射值有0，那就说明这个邮箱肯定不在这10亿内。
如果是一个黑名单对象，那么可以肯定的是所有映射都为1，肯定跑不了它。也就是说是坏人，一定会被抓。
那么误伤是为什么呢，就是指一些非黑名单对象的值经过k次哈希后，也全部为1，但它确实不是黑名单里的值，这种概率是存在的，但是是可控的。

至于具体实现，可以直接调用com.google.guava中的BloomFilter，就不赘述了。

缓存雪崩

平时我们设定一个缓存的过期时间时，可能有一些会设置1分钟啊，5分钟这些，并发很高时可能会出在某一个时间同时生成了很多的缓存，并且过期时间都一样，这个时候就可能引发一当过期时间到后，这些缓存同时失效，请求全部转发到DB，DB可能会压力过重。

解决方法

  1. 将缓存失效时间分散开，比如我们可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。
  2. 加锁或者队列的方式保证缓存的单线 程（进程）写，从而避免失效时大量的并发请求落到底层存储系统上。

热key重建

开发人员使用缓存 + 过期时间的策略既可以加速数据读写，又保证数据的定期更新，这种模式基本能够满足绝大部分需求。但是有两个问题如果同时出现，可能就会对应用造成致命的危害：

  • 当前 key 是一个热点 key( 例如一个热门的娱乐新闻），并发量非常大。
  • 重建缓存不能在短时间完成，可能是一个复杂计算，例如复杂的 SQL、多次IO、多个依赖等。

在缓存失效的瞬间，有大量线程来重建缓存 ( 如下图)，造成后端负载加大，甚至可能会让应用崩溃。

要解决这个问题也不是很复杂，但是不能为了解决这个问题给系统带来更多的麻烦，所以需要制定如下目标：

  • 减少重建缓存的次数
  • 数据尽可能一致
  • 较少的潜在危险

解决方案

1. 互斥锁

此方法只允许一个线程重建缓存，其他线程等待重建缓存的线程执行完，重新从缓存获取数据即可。

这种方案思路比较简单，但是存在一定的隐患，如果构建缓存过程出现问题或者时间较长，可能会存在死锁和线程池阻塞的风险，但是这种方法能够较好的降低后端存储负载并在一致性上做的比较好。

2. 不设置超时时间

“永远不过期”包含两层意思：

  • 从缓存层面来看，确实没有设置过期时间，所以不会出现热点key过期后产生的问题，也就是“物理”不过期。
  • 从功能层面来看，为每个value设置一个逻辑过期时间，当发现超过逻辑过期时间后，会使用单独的线程去构建缓存。

这种方案由于没有设置真正的过期时间，实际上已经不存在热点 key 产生的一系列危害，但是会存在数据不一致的情况，同时代码复杂度会增大。

http://mp.weixin.qq.com/s/TBCEwLVAXdsTszRVpXhVug
http://blog.csdn.net/tianyaleixiaowu/article/details/74721877
http://blog.csdn.net/zeb_perfect/article/details/54135506
https://zhuanlan.zhihu.com/p/26151305