缓存问题
- 分布式缓存
- Redis缓存雪崩
- Redis缓存击穿
- Redis缓存穿透
- 缓存预热
- 缓存降级
#Redis缓存雪崩
出现概率: ★★★★★
这个在Redis面试的题目中算是出镜率特别高的问题了, 建议仔细消化一下。
1)、缓存雪崩是指大量的缓存key无法在Redis缓存中进行处理，紧接着，短时间大量请求直接打到数据库层，导致数据库层的压力激增, 可能瞬间就会导致数据库宕机。
缓存雪崩一般是由两个原因导致的，应对方案也有所不同，我们一个个来看。
第一个原因是：缓存中有大量数据同时过期，比如说一些APP首页缓存数据，都设置了当天有效， 凌晨过期， 在第二天流量高峰时, 大量用户访问的请求， 没有换成从数据库中读取数据。如果应用的并发请求量很大，那么数据库的压力也突然变得很大，可能会造成缓存雪崩。
这种类似的问题解决思路也基本简单, 打散过期时间, 比如设置过期时间为 24小时之后 + 随机N分钟。
另外一个原因是Redis宕机, 这个就需要分析Redis宕机的原因了， 是因为磁盘满了还是内存满了, 根据情况进行处理，或者升配置什么的。 如果是内存满了, 也需要考虑是不是缓存过期回收策略的问题。
#Redis缓存击穿
出现概率: ★★★★
缓存击穿跟缓存雪崩有点类似，缓存雪崩是大规模的key失效，而缓存击穿是某个热点的key失效，大并发集中对其进行请求，就会造成大量请求读缓存没读到数据，从而导致高并发访问数据库，引起数据库压力剧增。这种现象就叫做缓存击穿。
解决方案：
a)、在缓存失效后，通过互斥锁或者队列来控制读数据写缓存的线程数量，比如某个key只允许一个线程查询数据和写缓存，其他线程等待。这种方式会阻塞其他的线程，此时系统的吞吐量会下降
b)、热点数据缓存永远不过期。
永不过期实际包含两层意思：
物理不过期，针对热点key不设置过期时间
逻辑过期，把过期时间存在key对应的value里，如果发现要过期了，通过一个后台的异步线程进行缓存的构建
#Redis缓存穿透
出现概率: ★★★★
缓存穿透是指用户请求的数据在缓存中不存在即没有命中，同时在数据库中也不存在，导致用户每次请求该数据都要去数据库中查询一遍。
如果短时间大量类似请求落在数据库上，造成数据库压力过大，可能导致数据库承受不住而宕机崩溃。
解决方法：
a)、将无效的key存放进Redis中：
当出现Redis查不到数据，数据库也查不到数据的情况，我们就把这个key保存到Redis中，设置value="null"，并设置其过期时间极短，后面再出现查询这个key的请求的时候，直接返回null，就不需要再查询数据库了。但这种处理方式是有问题的，假如传进来的这个不存在的Key值每次都是随机的，那存进Redis也没有意义。
b)、使用布隆过滤器：
如果布隆过滤器判定某个 key 不存在布隆过滤器中，那么就一定不存在，如果判定某个 key 存在，那么很大可能是存在(存在一定的误判率)。于是我们可以在缓存之前再加一个布隆过滤器，将数据库中的所有key都存储在布隆过滤器中，在查询Redis前先去布隆过滤器查询 key 是否存在，如果不存在就直接返回，不让其访问数据库，从而避免了对底层存储系统的查询压力。
#Redis缓存预热
出现概率: ★★★
缓存预热如字面意思，当系统上线时，缓存内还没有数据，如果直接提供给用户使用，每个请求都会穿过缓存去访问底层数据库，如果并发大的话，很有可能在上线当天就会宕机，因此我们需要在上线前先将数据库内的热点数据缓存至Redis内再提供出去使用，这种操作就成为"缓存预热"。
缓存预热的实现方式有很多，比较通用的方式是写个批任务，在启动项目时或定时去触发将底层数据库内的热点数据加载到缓存内。
#Redis缓存降级
出现概率: ★★★
缓存降级是指当访问量剧增、服务出现问题（如响应时间慢或不响应）或非核心服务影响到核心流程的性能时，即使是有损部分其他服务，仍然需要保证主服务可用。可以将其他次要服务的数据进行缓存降级，从而提升主服务的稳定性。
降级的目的是保证核心服务可用，即使是有损的。如去年双十一的时候淘宝购物车无法修改地址只能使用默认地址，这个服务就是被降级了，这里阿里保证了订单可以正常提交和付款，但修改地址的服务可以在服务器压力降低，并发量相对减少的时候再恢复。
