分布式-Redis-缓存问题

缓存问题

缓存雪崩

原有缓存失效，新缓存未到期间,大量数据打垮DB。

比如程序首页大面积的缓存设置了相同的过期时间，同一时刻缓存失效，流量激增，DB撑不住，挂掉。

解决办法:

1、在批量往Redis存数据的时候，把每个Key的失效时间都加个随机值就好了，这样可以保证数据不会在同一时间大面积失效

2、如果Redis是集群部署，将热点数据均匀分布在不同的Redis库中也能避免全部失效的问题

3、设置热点数据永远不过期，有更新操作就更新缓存就好了（比如运维更新了首页商品，那你刷下缓存就完事了，不要设置过期时间），电商首页的数据也可以用这个操作，保险。

防止雪崩方案可以参考下图：

缓存穿透

缓存和数据库中都没有的数据，而用户不断发起请求，导致数据压力过大，甚至击垮数据库

比如黑客会对你的系统进行攻击，拿一个不存在的id 去查询数据，会产生大量的请求到数据库去查询。可能会导致你的数据库由于压力过大而宕掉

解决办法：

1、在接口增加校验

2、在网关Nginx增加配置顶，对单个ip每秒访问次数超出阈值的ip都给拉黑

3、如果一个查询返回的数据为空（不管数据是否存在，还是系统故障），仍然将这个空结果缓存

4、布隆过滤器：利用高效的数据结构和算法快速判断key是否存在数据库，不存在直接return，存在则去查询DB刷新KV再return

缓存击穿

缓存击穿是指一个Key非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个Key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，就像在一个完好无损的桶上凿开了一个洞

解决办法:

1、设置热点数据永不过期

2、增加互斥锁

缓存预热

就是系统上线后，将缓存数据直接加载到缓存系统。这样用户请求，不用先查询数据库，再将数据缓存。直接查询事先被预热的数据

解决办法:

1、直接写个缓存页面，上线时手工操作下

2、数据量不大的话，在项目启动的时候自动进行加载

3、定时刷新缓存

缓存更新

除了缓存服务器自带的缓存失效策略之外（Redis默认的有6中策略可供选择），我们还可以根据具体的业务需求进行自定义的缓存淘汰，常见的策略有两种：

1、定时去清理过期的缓存；

2、当有用户请求过来时，再判断这个请求所用到的缓存是否过期，过期的话就去底层系统得到新数据并更新缓存。

两者各有优劣，第一种的缺点是维护大量缓存的key是比较麻烦的，第二种的缺点就是每次用户请求过来都要判断缓存失效，逻辑相对比较复杂！具体用哪种方案，没有最好，只有最合适！

缓存降级

当访问量剧增、服务出现问题（如响应时间慢或不响应）或非核心服务影响到核心流程的性能时，仍然需要保证服务还是可用的，即使是有损服务。系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级。

降级的最终目的是保证核心服务可用，即使是有损的。而且有些服务是无法降级的（如加入购物车、结算）。

在进行降级之前要对系统进行梳理，看看系统是不是可以丢卒保帅；从而梳理出哪些必须誓死保护，哪些可降级；比如可以参考日志级别设置预案：

（1）一般：比如有些服务偶尔因为网络抖动或者服务正在上线而超时，可以自动降级；

（2）警告：有些服务在一段时间内成功率有波动（如在95~100%之间），可以自动降级或人工降级，并发送告警；

（3）错误：比如可用率低于90%，或者数据库连接池被打爆了，或者访问量突然猛增到系统能承受的最大阀值，此时可以根据情况自动降级或者人工降级；

发送告警；

（3）错误：比如可用率低于90%，或者数据库连接池被打爆了，或者访问量突然猛增到系统能承受的最大阀值，此时可以根据情况自动降级或者人工降级；

（4）严重错误：比如因为特殊原因数据错误了，此时需要紧急人工降级

Redis总结

参考：https://blog.csdn.net/xlgen157387/article/details/79530877