分布式面试之Solr以及redis的面试问题

redis之雪崩问题的解决：首先redis做缓存，应用场景一般如下：

Redis做缓存是最常见的应用场景。客户端请求在缓存层命中就直接返回，如果miss就去读取存储层，存储层读取到就写入缓存层，然后再返回到客户端。 
优点： 
加速读写 
降低后端负载 
缺点： 
数据的不一致性 
代码维护成本 
运维成本

缓存穿透化:

然而缓存可能会遇到这种问题：请求cache拿不到数据，就会去存储层拿，都拿不到时，返回空值（可能会返回大量空值）。或者代码有问题，拿不到数据。就会一直请求数据。导致后端打崩。

优化方法：
1、缓存层缓存空值。
–缓存太多空值，占用更多空间。（优化：给个空值过期时间）
–存储层更新代码了，缓存层还是空值。（优化：后台设置时主动删除空值，并缓存把值进去）

redis:雪崩优化

redis挂了，客户端直接请求到数据库里面。数据库负载非常高。甚至数据库拖挂了。

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

redis:弱点key优化

A、B、C、D同时请求一个资源，不存在时都要去请求存储层，有可能会拖挂。

优化方法： 
1、互斥锁： 
只允许一个请求重建缓存。 
其他请求等待缓存重建执行完，重新从缓存获取数据即可。 

2、用户过期 
–“物理”不过期 
–逻辑设置过期时间（根据上一次更新时间，构建一个队列，主动去更新） 
热点key重建优化