Redis相关

缓存穿透和缓存雪崩

缓存穿透

在查询一个一定不存在的数据,由于缓存是不命中时被动写入,并且处于容错考虑,如果从存储层查不到数据则不写入缓存,这将导致这个不存在的数据每次请求都要到存储层去查询,缓存层失去意义。
当在大流量流入时,可能因为频繁访问存储层导致DB直接宕机,这样会形成被人利用不存在的key频繁攻击应用的漏洞。

解决方案:

1.布隆过滤器(最常用)。将所有可能存在的数据哈希到一个 bigmap 中,一个一定不存在的数据会被该 bigmap 拦截掉,从而避免对底层存储系统造成查询压力。
什么是布隆过滤器
https://www.jianshu.com/p/2104d11ee0a2

2.另一种更为简单的方法,如果一个查询返回的数据为空(无论数据为空,或是系统故障),将空结果进行缓存,设置一个最长不超过五分钟的过期时间。(个人感觉这个也太简单粗暴了,不太推荐吧)

缓存雪崩

设置缓存时采用了相同的过期时间,导致缓存在某时刻同时失效,请求全部转向DB,DB瞬时压力过重雪崩。
Redis宕机,导致客户端的请求之间流向DB,拖垮DB。
问题一的解决方案

1.在缓存失效后,通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存,其他线程等待。
2.简单方案就是将缓存失效时间分散开,我们可以在原有的失效时间基础上增加一个随机值,比如1-5分钟随机,这样每一个缓存的过期时间的重复率就会降低,就很难引发集体失效的事件。
3.设置热点数据永远不过期。

问题二的解决方案

保持缓存层服务器的高可用。
–监控、集群、哨兵。当一个集群里面有一台服务器有问题,让哨兵踢出去。
依赖隔离组件为后端限流并降级。
比如推荐服务中,如果个性化推荐服务不可用,可以降级为热点数据。
提前演练。
演练 缓存层crash后,应用以及后端的负载情况以及可能出现的问题。 对此做一些预案设定。

缓存击穿

缓存击穿是指缓存中没有但数据库中有的数据(一般是缓存时间到期),这时由于并发用户特别多,同时读缓存没读到数据,又同时去数据库去取数据,引起数据库压力瞬间增大,造成过大压力

解决方案:
1.设置热点数据永远不过期。
2.加互斥锁,其实思路和雪崩的解决方案一same,不过是一个是同一个key,一个是多个key

缓存击穿和缓存雪崩的不同:缓存击穿指并发查同一条数据,缓存雪崩是不同数据都过期了,很多数据都查不到从而查数据库。

redis LRU和LFU的底层实现原理

https://www.jianshu.com/p/c8aeb3eee6bc

而redis的热点发现机制就是基于LFU
redis于4.0.3版本开始正式支持基于LFU的热点key发现机制:
https://blog.csdn.net/weixin_33670786/article/details/90276828

如何保证Redis中的数据都是热点数据?

首先热点数据是什么
如果是活跃的用户数据。
redis sortSet里 放两天内(为方便取一天内活跃用户)登录过的用户,登录一次ZADD一次,如set已存在则覆盖其分数(登录时间)。键:login:users,值:分数 时间戳、value userid。设置一个周期任务,比如每天03:00:00点删除sort set中前一天3点前的数据(保证set不无序增长、留近一天内活跃用户)。获取数据时,拿到当前时间戳(int 10位),再减1天就可按分数范围取过去24h活跃用户。

redis 内存数据集大小上升到一定大小的时候,会施行数据淘汰策略。

redis 提供 6种数据淘汰策略:

redis 内存数据集大小上升到一定大小的时候,就会施行数据淘汰策略。redis 提供 6种数据淘汰策略:
volatile-lru:从已设置过期时间的数据集(server.db[i].expires)中挑选最近最少使用的数据淘汰
volatile-ttl:从已设置过期时间的数据集(server.db[i].expires)中挑选将要过期的数据淘汰
volatile-random:从已设置过期时间的数据集(server.db[i].expires)中任意选择数据淘汰
allkeys-lru:从数据集(server.db[i].dict)中挑选最近最少使用的数据淘汰
allkeys-random:从数据集(server.db[i].dict)中任意选择数据淘汰
no-enviction(驱逐):禁止驱逐数据

影响缓存命中率的几个因素

之前的章节中我们提到了缓存命中率的重要性,下面分析下影响缓存命中率的几个因素。

1.业务场景和业务需求
缓存适合“读多写少”的业务场景,反之,使用缓存的意义其实并不大,命中率会很低。

业务需求决定了对时效性的要求,直接影响到缓存的过期时间和更新策略。时效性要求越低,就越适合缓存。在相同key和相同请求数的情况下,缓存时间越长,命中率会越高。

互联网应用的大多数业务场景下都是很适合使用缓存的。

2.缓存的设计(粒度和策略)
通常情况下,缓存的粒度越小,命中率会越高。举个实际的例子说明:

当缓存单个对象的时候(例如:单个用户信息),只有当该对象对应的数据发生变化时,我们才需要更新缓存或者让移除缓存。而当缓存一个集合的时候(例如:所有用户数据),其中任何一个对象对应的数据发生变化时,都需要更新或移除缓存。

还有另一种情况,假设其他地方也需要获取该对象对应的数据时(比如其他地方也需要获取单个用户信息),如果缓存的是单个对象,则可以直接命中缓存,反之,则无法直接命中。这样更加灵活,缓存命中率会更高。

此外,缓存的更新/过期策略也直接影响到缓存的命中率。当数据发生变化时,直接更新缓存的值会比移除缓存(或者让缓存过期)的命中率更高,当然,系统复杂度也会更高。

3.缓存容量和基础设施
缓存的容量有限,则容易引起缓存失效和被淘汰(目前多数的缓存框架或中间件都采用了LRU算法)。同时,缓存的技术选型也是至关重要的,比如采用应用内置的本地缓存就比较容易出现单机瓶颈,而采用分布式缓存则毕竟容易扩展。所以需要做好系统容量规划,并考虑是否可扩展。此外,不同的缓存框架或中间件,其效率和稳定性也是存在差异的。

4.其他因素
当缓存节点发生故障时,

redis一致性哈希和哈希槽

https://www.jianshu.com/p/4163916a2a8a

redis位图的妙用

https://www.jianshu.com/p/305e65de1b13

你可能感兴趣的:(Redis相关)