redis之雪崩问题的解决：首先redis做缓存，应用场景一般如下：
Redis做缓存是最常见的应用场景。客户端请求在缓存层命中就直接返回，如果miss就去读取存储层，存储层读取到就写入缓存层，然后再返回到客户端。
优点：
加速读写
降低后端负载
缺点：
数据的不一致性
代码维护成本
运维成本
缓存穿透化:
然而缓存可能会遇到这种问题：请求cache拿不到数据，就会去存储层拿，都拿不到时，返回空值（可能会返回大量空值）。或者代码有问题，拿不到数据。就会一直请求数据。导致后端打崩。
优化方法：
1、缓存层缓存空值。
–缓存太多空值，占用更多空间。（优化：给个空值过期时间）
–存储层更新代码了，缓存层还是空值。（优化：后台设置时主动删除空值，并缓存把值进去）
redis:雪崩优化
redis挂了，客户端直接请求到数据库里面。数据库负载非常高。甚至数据库拖挂了。
优化方法：
1、保持缓存层服务器的高可用。
–监控、集群、哨兵。当一个集群里面有一台服务器有问题，让哨兵踢出去。
2、依赖隔离组件为后端限流并降级。
比如推荐服务中，如果个性化推荐服务不可用，可以降级为热点数据。
3、提前演练。
演练 缓存层crash后，应用以及后端的负载情况以及可能出现的问题。
对此做一些预案设定。
redis:弱点key优化
A、B、C、D同时请求一个资源，不存在时都要去请求存储层，有可能会拖挂。
优化方法：
1、互斥锁：
只允许一个请求重建缓存。
其他请求等待缓存重建执行完，重新从缓存获取数据即可。
2、用户过期
–“物理”不过期
–逻辑设置过期时间（根据上一次更新时间，构建一个队列，主动去更新）
热点key重建优化
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
