一、redis 更新策略
- 1.定时更新缓存
可能会引起雪崩，后文细说 - 2.查询不到更新
可以为每个缓存数据，配置一个相应的version缓存。 配置时先适配version，后取相应缓存，以减少序列化时间调高效率。
二、redis穿透
故障描述： 缓存与数据库都没有的数据，发起大量访问请求，对后端造成很大的压力。要是有人利用不存在的key频繁攻击我们的应用，这就是漏洞。
解决方案：
1.缓存层缓存空值。
–缓存太多空值，占用更多空间。（优化：给个空值过期时间）
–存储层更新代码了，缓存层还是空值。（优化：后台设置时主动删除空值，并缓存把值进去）
2.将数据库中所有的查询条件，放到布隆过滤器中。当一个查询请求来临的时候，先经过布隆过滤器进行检查，如果请求存在这个条件中，那么继续执行，如果不在，直接丢弃。
3.接口参数验签，过滤掉特殊值，比如id= -1
4.布隆过滤器
redis中的布隆过滤器bloomfilter
redis 在 4.0 的版本中加入了 module 功能，布隆过滤器可以通过 module 的形式添加到 redis 中。
bloomfilter就类似于一个hash set，用于快速判某个元素是否存在于集合中，
其典型的应用场景就是
将所有可能存在的数据缓存，放到布隆过滤器中，当黑客访问不存在的缓存时迅速返回避免缓存及DB挂掉。
布隆过滤器存在一个定的误判率，大约是八百万数据量，百分之二的误判率。
三、redis击穿
故障描述： 热点单个key，过期，此时迎来高并发
对于一些设置了过期时间的key，如果这些key可能会在某些时间点被超高并发地访问，是一种非常“热点”的数据。这个时候，需要考虑一个问题：缓存被“击穿”的问题，这个和缓存雪崩的区别在于这里针对某一key缓存，前者则是很多key。
场景一:微博上，某某明星传绯闻，两个明星主页被刷爆
缓存在某个时间点过期的时候，恰好在这个时间点对这个Key有大量的并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。
解决方案：
1.使用互斥锁(mutex key)
业界比较常用的做法，是使用mutex。简单地来说，就是在缓存失效的时候（判断拿出来的值为空），不是立即去load db，而是先使用缓存工具的某些带成功操作返回值的操作（比如Redis的SETNX或者Memcache的ADD）去set一个mutex key，当操作返回成功时，再进行load db的操作并回设缓存；否则，就重试整个get缓存的方法。
"提前"使用互斥锁(mutex key)：
在value内部设置1个超时值(timeout1), timeout1比实际的memcache timeout(timeout2)小。当从cache读取到timeout1发现它已经过期时候，马上延长timeout1并重新设置到cache。然后再从数据库加载数据并设置到cache中。"永远不过期"：
这里的“永远不过期”包含两层意思：
(1) 从redis上看，确实没有设置过期时间，这就保证了，不会出现热点key过期问题，也就是“物理”不过期。
(2) 从功能上看，如果不过期，那不就成静态的了吗？所以我们把过期时间存在key对应的value里，如果发现要过期了，通过一个后台的异步线程进行缓存的构建，也就是“逻辑”过期
4.资源保护：
采用netflix的hystrix，可以做资源的隔离保护主线程池，如果把这个应用到缓存的构建也未尝不可
5.为即将过期的key，续命：
缓存中取值，发现即将过期，追加一个小的时间值，延长有效期。
6.限流： 比如说使用消息队列，让流量在消息队列中囤积下，逐个消费，缓解后端压力。
四、redis雪崩
故障描述：
缓存雪崩是指在我们设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到DB，DB瞬时压力过重雪崩
场景一：同一时间点，缓存全部失效：
比如：有的电商网站在项目重启时，将全部商品信息加入缓存中，并设置等长的有效期。到某一时间点，缓存有效期过期，大量缓存失效，如果遇上高并发，请求全部打在后端数据库上。
场景二：穿透诱发雪崩
短时间内大量的请求无法命中缓存，请求穿透到数据库，导致数据库繁忙，请求超时。
大量的请求超时还会引发更多的重试请求，更多的重试请求让数据库更加繁忙，这样恶性循环导致系统雪崩。
解决方案：
1.设置缓存超时时间的时候加上一个随机的时间长度，比如这个缓存key的超时时间是固定的5分钟加上随机的2分钟，酱紫可从一定程度上避免雪崩问题；
2.热点数据永不过期，数据库更新时同步更新缓存 （如：电商首页信息）
3.互斥锁排队
根据key获取value值为空时，锁上，从数据库中load数据后再释放锁。若其它线程获取锁失败，则等待一段时间后重试。这里要注意，分布式环境中要使用分布式锁（Redisson），单机的话用普通的锁（synchronized、Lock）
- 灰度发布 + cahe Aside缓存更新策略：
cahe Aside就是由升哥提供的我们沿用至今的缓存更新策略：
应用程序先从缓存中取数据，不存在，则从数据库中取数据，成功后，放到缓存中。
更新是先更新数据库，成功后，让缓存失效
可以配合采用灰度发布的方式，先接入少量请求，再逐步增加系统的请求数量，直到全部请求都切换完成。
