6.Redis对象回收策略及缓存击穿穿透雪崩场景

当Redis所用内存打到maxmemory上限时会触发响应的溢出控制策略 具体策略受 redis.conf文件  maxmemory-policy参数控制

Redis支持6种策略：

• noeviction： 默认策略，不会删除任何数据，拒绝所有写入操作并返回客户端错误信息，此时Redis只响应读操作。

• volatitle-rlu：根据LRU算法删除设置了超时属性的键，直到腾出足够空间为止。如果没有可删除的键对象，回退到noeviction策略。

• allkeys-lru： 根据LRU算法删除键，不管数据有没有设置超时属性，直到腾出足够空间为止。

• allkeys-random：随机删除所有键，直到腾出足够空间为止。

• volatitle-random：随机删除过期键，直到腾出足够空间为止。

• volatitle-ttl：根据键值对象的ttl属性，删除最近将要过期数据。如果没有，回退到noeviction策略

如何应对缓存穿透与缓存雪崩的问题？

场景	定义	解决方案
缓存穿透	缓存穿透是指查询一个一定不存在的数据，由于缓存是不命中时才会写入缓存，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。在流量大时，可能DB就挂掉了，要是有人利用不存在的key频繁攻击我们的应用，这就是漏洞	方案一： 1.在redis保存key的时候，写入布隆过滤器，然后查询的时候在先查询布隆过滤器 2.是采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被 这个bitmap拦截掉，从而避免了对底层存储系统的查询压力；【布隆过滤器的原理是，当一个元素被加入集合时，通过K个Hash函数将这个元素映射成一个位数组中的K个点，把它们置为1。检索时，我们只要看看这些点是不是都是1就（大约）知道集合中有没有它了：如果这些点有任何一个0，则被检元素一定不在；如果都是1，则被检元素很可能在。这就是布隆过滤器的基本思想。】   方案二： 3.另外一种方法，如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟.   方案三： 4.最方便的解决方案在穿透服务访问DB加入限流保护，对限流外的请求直接还回” “，然后从db更新回值到redis缓存。
缓存雪崩	缓存雪崩是指在我们设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到DB，DB瞬时压力过重雪崩.	方案一： 缓存失效时的雪崩效应对底层系统的冲击非常可怕。大多数系统设计者考虑用加锁或者队列的方式保证缓存的单线程操作，从而避免失效时大量的并发请求落到底层存储系统上。其实可以在原有的失效时间基础上增加一个随机值，这样缓存的过期时间的重复率就会降低，就很难引发集体失效的事件
缓存击穿	对于一些设置了过期时间的key，如果这些key可能会在某些时间点被超高并发地访问，是一种非常“热点”的数据。这个时候，需要考虑一个问题：缓存被“击穿”的问题，这个和缓存雪崩的区别在于这里针对某一key缓存，前者则是很多key。   缓存在某个时间点过期的时候，恰好在这个时间点对这个Key有大量的并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮	方案一： 1.使用互斥锁(mutex key)：就是在缓存失效的时候，不是立即去底层数据库取值，而是先使用缓存工具的某些带成功操作返回值的操作去set一个mutex key，当操作返回成功时，再进行load db的操作并回设缓存；否则，就重试整个get缓存的方法。加锁排队只是为了减轻数据库的压力，并没有提高系统吞吐量；   2.在value内部设置1个超时值(timeout1), timeout1比实际的memcache timeout(timeout2)小。当从cache读取到timeout1发现它已经过期时候，马上延长timeout1并重新设置到cache。然后再从数据库加载数据并设置到cache中   方案二： 3.最方便的解决方案在穿透服务访问DB加入限流保护，对限流外的请求直接还回” “，后续更新会redis
数据一致性	对于变更数据库和redis数据的场景 考虑数据更新失败的场景	redis更新写在mysql更新语句后面 防止mysql更新失败后redis有垃圾数据