① 缓存击穿、穿透、雪崩及Redis分布式锁
分布式锁: setnx ,redisson 并发问题
幂等问题: 落表状态,Redis
缓存击穿: 指缓存中无,db中有
原因: 一个key高并发恰好失效导致大量请求到db
方案: 加锁,自旋锁,或一个线程查db,一个线程监控(直接用Redisson分布式锁)
缓存穿透:指缓存和db中均无
原因: 一般是恶意请求
方案: 加布隆过滤,或查db无时,也设置缓存,value为某些特殊表示或"null"
雪崩:指缓存同时大量失效
原因: 大量的key同时失效,db压力加大
方案: 设置失效时间是增加随机数
问题方案文献:
https://www.jianshu.com/p/31ab9b020cd9 (图例分析)
https://blog.csdn.net/fcvtb/article/details/89478554
Redis分布式锁:
事务未执行完锁已到期释放问题：使用Redissoin解决续租问题，内部已解决
分布式锁文献:
https://www.jianshu.com/p/4838f8be00c9
https://blog.csdn.net/qq_30038111/article/details/90696233 (setnx + expire同时操作)
====================================
https://www.runoob.com/redis/keys-scan.html
https://www.jianshu.com/p/611a492d9121 Redis原理与应用
② Redis缓存雪崩就这么简单
在实际项目开发中，我们都知道Redis不可能把所有的数据都缓存起来( 内存昂贵且有限 )，所以Redis需要对数据设置过期时间，并采用的是惰性删除+定期删除两种策略对过期键删除。
如果缓存数据 设置的过期时间是相同 的，并且Redis恰好将这部分数据全部删光了。这就会导致在这段时间内，这些缓存 同时失效 ，全部请求到数据库中。
这就是缓存雪崩 ：
缓存雪崩如果发生了，很可能就把我们的数据库 搞垮 ，导致整个服务瘫痪，造成的后果很严重。
对缓存数据设置相同的过期时间，导致某段时间内缓存失效。”
对于“Redis挂掉了”，我们可以有以下的思路：
③ java清缓存前可以进后台方法,清完缓存不进了
关于java清缓存前可以进后台方法,清完缓存不进了相关资料如下
java我们在使用缓存时，往往先尝试去缓存中取值，如果没有，再去数据库取值，如果数据库也没有值，则根据业务需求，返回空或者抛异常。
如果用户一直访问一个数据库不存在的数据，比如id为-1的数据，就会导致每次请求都会先去缓存查一次，然后再去数据库查一次，造成严重的性能问题。这种情况就叫缓存穿透。
解决方案
以下几种解决方案：对请求参数做校验，比如用户鉴权校验，id做基础校验，id <= 0的直接拦截。
如果查询到数据库没有值，也将对应的key存进缓存中，value为null。这样下次查询就直接从缓存返回了。但这里的key的缓存时间应该比较短，比如30s。防止后面在数据库插入了这条数据，而用户获取不到。
使用布隆过滤器，判断一个key是否已经查过了，如果已经查过了，就不去数据库查询。
缓存击穿
缓存击穿指的是，一个key的访问量非常大，比如某秒杀活动，有1w/s的并发量。这个key在某一时刻过期，那这些大量的请求就会一瞬间到数据库，数据库可能会直接崩溃。
解决方案
缓存击穿的解决方案也有几种，可以配合使用：对于热点数据，慎重考虑过期时间，确保热点期间key不会过期，甚至有些可以设置永不过期。
使用互斥锁(比如Java的多线程锁机制)，第一个线程访问key的时候就锁住，等查询数据库返回后，把值插入到缓存后再释放锁，这样后面的请求就可以直接取缓存里面的数据了。
缓存雪崩
缓存雪崩指的是，在某一时刻，多个key失效。这样就会有大量的请求从缓存中获取不到值，全部到数据库。还有另一种情况，就是缓存服务器宕机，也算做缓存雪崩。
解决方案
针对上述两种情况，缓存雪崩有两种解决方案：对每个key的过期时间设置一个随机值，而不是所有key都相同。
使用高可用的分布式缓存集群，确保缓存的高可用性，比如redis-cluster。
④ 该怎么解决 Redis 缓存穿透和缓存雪崩问题
缓存雪崩： 由于缓存层承载着大量请求，有效地 保护了存储层，但是如果缓存层由于某些原因不能提供服务，比如 Redis 节点挂掉了，热点 key 全部失效了，在这些情况下，所有的请求都会直接请求到数据库，可能会造成数据库宕机的情况。
预防和解决缓存雪崩问题，可以从以下三个方面进行着手：
1、使用 Redis 高可用架构：使用 Redis 集群来保证 Redis 服务不会挂掉
2、缓存时间不一致： 给缓存的失效时间，加上一个随机值，避免集体失效
3、限流降级策略：有一定的备案，比如个性推荐服务不可用了，换成热点数据推荐服务
缓存穿透： 缓存穿透是指查询一个根本不存在的数据，这样的数据肯定不在缓存中，这会导致请求全部落到数据库上，有可能出现数据库宕机的情况。
预防和解决缓存穿透问题，可以考虑以下两种方法：
1、缓存空对象： 将空值缓存起来，但是这样就有一个问题，大量无效的空值将占用空间，非常浪费。
2、布隆过滤器拦截： 将所有可能的查询key 先映射到布隆过滤器中，查询时先判断key是否存在布隆过滤器中，存在才继续向下执行，如果不存在，则直接返回。布隆过滤器有一定的误判，所以需要你的业务允许一定的容错性。
⑤ redis常见问题
1. 缓存击穿
缓存击穿是指一个请求要访问的数据，缓存中没有，但数据库中有的情况。这种情况一般都是缓存过期了。
但是这时由于并发访问这个缓存的用户特别多，这是一个热点 key，这么多用户的请求同时过来，在缓存里面没有取到数据，所以又同时去访问数据库取数据，引起数据库流量激增，压力瞬间增大，直接崩溃给你看。
所以一个数据有缓存，每次请求都从缓存中快速的返回了数据，但是某个时间点缓存失效了，某个请求在缓存中没有请求到数据，这时候我们就说这个请求就"击穿"了缓存。
针对这个场景，对应的解决方案一般来说有三种。
借助Redis setNX命令设置一个标志位就行。设置成功的放行，设置失败的就轮询等待。就是在更新缓存时加把锁
后台开一个定时任务，专门主动更新过期数据
比如程序中设置 why 这个热点 key 的时候，同时设置了过期时间为 10 分钟，那后台程序在第 8 分钟的时候，会去数据库查询数据并重新放到缓存中，同时再次设置缓存为 10 分钟。
其实上面的后台续命思想的最终体现是也是永不过期。
只是后台续命的思想，会主动更新缓存，适用于缓存会变的场景。会出现缓存不一致的情况，取决于你的业务场景能接受多长时间的缓存不一致。
2. 缓存穿透
缓存穿透是指一个请求要访问的数据，缓存和数据库中都没有，而用户短时间、高密度的发起这样的请求，每次都打到数据库服务上，给数据库造成了压力。一般来说这样的请求属于恶意请求。
解决方案有两种：
就是在数据库即使没有查询到数据，我们也把这次请求当做 key 缓存起来，value 可以是 NULL。下次同样请求就会命中这个 NULL，缓存层就处理了这个请求，不会对数据库产生压力。这样实现起来简单，开发成本很低。
3. 缓存雪崩
缓存雪崩是指缓存中大多数的数据在同一时间到达过期时间，而查询数据量巨大，这时候，又是缓存中没有，数据库中有的情况了。
防止雪崩的方案简单来说就是错峰过期。
在设置 key 过期时间的时候，在加上一个短的随机过期时间，这样就能避免大量缓存在同一时间过期，引起的缓存雪崩。
如果发了雪崩，我们可以有服务降级、熔断、限流手段来拒绝一些请求，保证服务的正常。但是，这些对用户体验是有一定影响的。
4. Redis 高可用架构
Redis 高可用架构，大家基本上都能想到主从、哨兵、集群这三种模式。
哨兵模式：
它主要执行三种类型的任务：
哨兵其实也是一个分布式系统，我们可以运行多个哨兵。
然后这些哨兵之间需要相互通气，交流信息，通过投票来决定是否执行自动故障迁移，以及选择哪个从服务器作为新的主服务器。
哨兵之间采用的协议是 gossip，是一种去中心化的协议，达成的是最终一致性。
选举规则：
⑥ 面试时问到一个问题，什么是缓存雪崩
缓存雪崩，就是大量数据同一时间失效。
解决办法：
1.缓存数据的过期时间设置随机，防止同一时间大量数据过期现象发生。
2.如果缓存数据库是分布式部署，将热点数据均匀分布在不同的缓存数据库中。