布隆过滤器Redis缓存穿透雪崩击穿热点key

目录

布隆过滤器Redis 缓存穿透雪崩击穿热点KEY

布隆过滤器

布隆过滤器（判断某个key一定不存在）

本质上布隆过滤器是一种数据结构，比较巧妙的概率型数据结构特点是高效地插入和查询，可以用来告诉你 “某样东西一定不存在或者可能存在”相比于传统的 List、Set、Map 等数据结构，它更高效、占用空间更少，但是缺点是其返回的结果是概率性的，而不是确切的

布隆过滤器的使用：

布隆过滤器在NoSQL数据库领域中应用的非常广泛当用户来查询某一个row时，可以先通过内存中的布隆过滤器过滤掉大量不存在的row请求，然后去再磁盘进行查询布隆过滤器说某个值不存在时，那肯定就是不存在，可以显著降低数据库IO请求数量

应用场景

场景1（给用户推荐新闻） 当用户看过的新闻，肯定会被过滤掉，对于没有看多的新闻，可能会过滤极少的一部分（误判）这样可以完全保证推送给用户的新闻都是无重复的 场景2（爬虫url去重） 在爬虫系统中，我们需要对url去重，已经爬取的页面不再爬取当url高达几千万时，如果一个集合去装下这些URL地址非常浪费空间使用布隆过滤器可以大幅降低去重存储消耗，只不过也会使爬虫系统错过少量页面

布隆过滤器原理

添加：值到布隆过滤器

向布隆过滤器添加key,会使用 f、g、h hash函数对key算出一个整数索引，然后对长度取余每个hash函数都会算出一个不同的位置，把算出的位置都设置成1就完成了布隆过滤器添加过程

查询：布隆过滤器值

当查询某个key时，先用hash函数算出一个整数索引，然后对长度取余当你有一个不为1时肯定不存在这个key，当全部都为1时可能有这个key这样内存中的布隆过滤器过滤掉大量不存在的row请求，然后去再磁盘进行查询，减少IO操作

删除：不支持

目前我们知道布隆过滤器可以支持 add 和 isExist 操作如何解决这个问题，答案是计数删除，但是计数删除需要存储一个数值，而不是原先的 bit 位，会增大占用的内存大小增加一个值就是将对应索引槽上存储的值加一，删除则是减一，判断是否存在则是看值是否大于0

Redis 缓存

客户端请求在缓存层命中直接返回内容，如果Miss就去存储层读取，存储层读取到数据再写入缓存层，然后再返回客户端。

优点：

加速读写效率降低后端负载减少存储层压力

缺点：

数据不能保证一致性代码维护成本和运维成本

主从复制

主节点数据更新后根据配置和策略，自动同步到备节点的master/slaver的机制主节点负责写数据，从节点负责读数据主节点定期把数据同步到从节点保证数据的一致性

优点：

读写分离容灾恢复

缺点：

主从复制，若主节点出现问题，则不能提供服务，需要人工修改配置将从变主主从复制主节点的写能力单一，能力有限单机节点的存储能力也有限

穿透

定义

缓存穿透是指查询一个一定不存在的数据，由于缓存不命中，接着查询数据库也无法查询出结果虽然也不会写入到缓存中，但是这将会导致每个查询都会去请求数据库，造成缓存穿透在查询一个不存在的数据时，在缓存层查不到数据则会去访问存储层，且返回的空数据也不会写入缓存层。这将导致不存在的数据每次查询都必定会到存储层查询，缓存层失去了存在的意义当大量恶意查询不存在数据时，可能因为频繁访问导致数据库宕机

解决方法 ：布隆过滤

对所有可能查询的参数以hash形式存储，在控制层先进行校验，不符合则丢弃，将所有可能存在的数据哈希到一个足够发的 bigmap 中一个一定不存在的数据会被该 bigmap 拦截掉，从而避免对底层存储系统造成查询压力 【推荐】如果一个查询返回的数据为空（无论数据为空，或是系统故障），将空结果进行缓存，设置一个最长不超过五分钟的过期时间。这样过期时间内查询的时候就会直接在缓存层获取，并直接返回null

雪崩

定义

缓存雪崩是指，由于缓存层承载着大量请求，有效的保护了存储层，但是如果缓存层由于某些原因整体不能提供服务于是所有的请求都会达到存储层，存储层的调用量会暴增，造成存储层也会挂掉的情况

解决方法

哨兵主服务器宕机，从服务器会主动切换成主服务器事前：redis 高可用，主从+哨兵，redis cluster，避免全盘崩溃。事中：本地 ehcache 缓存 + hystrix 限流&降级，避免 MySQL 被打死。事后：redis 持久化，一旦重启，自动从磁盘上加载数据，快速恢复缓存数据。

击穿

定义：

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

解决方法

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

热点KEY

热点问题产生的原因大致有以下两种：

用户消费的数据远大于生产的数据（热卖商品、热点新闻、热点评论、明星直播）

在日常工作生活中一些突发的的事件，例如：

双十一期间某些热门商品的降价促销，当这其中的某一件商品被数万次点击浏览或者购买时，会形成一个较大的需求量，这种情况下就会造成热点问题。

同理，被大量刊发、浏览的热点新闻、热点评论、明星直播等，这些典型的读多写少的场景也会产生热点问题

在服务端读数据进行访问时，往往会对数据进行分片切分

此过程中会在某一主机 Server 上对相应的 Key 进行访问，当访问超过 Server 极限时，就会导致热点 Key 问题的产生

热点问题的危害

• 流量集中，达到物理网卡上限。

• 请求过多，缓存分片服务被打垮。

• DB 击穿，引起业务雪崩。

如何解决热点key的问题

利用二级缓存

比如利用 ehcache ，或者一个 HashMap 都可以。在你发现热key以后，把热key加载到系统的JVM中。

针对这种热key请求，会直接从jvm中取，而不会走到redis层。

假设此时有十万个针对同一个key的请求过来,如果没有本地缓存，这十万个请求就直接怼到同一台redis上了。

现在假设，你的应用层有50台机器，OK，你也有jvm缓存了。这十万个请求平均分散开来，每个机器有2000个请求，会从JVM中取到value值，然后返回数据。避免了十万个请求怼到同一台redis上的情形。

(2)备份热key

这个方案也很简单。不要让key走到同一台redis上不就行了。我们把这个key，在多个redis上都存一份不就好了。接下来，有热key请求进来的时候，我们就在有备份的redis上随机选取一台，进行访问取值，返回数据。

来自于参考博客参考博客链接