redis(七)：击穿、穿透、雪崩、分布式锁

击穿

• 产生场景：如果一个key很长时间没有被访问，变为冷数据，则该key会从缓存中删除，如果刚好在这个时点下，发生了高并发请求该key，却发现缓存中没有该key，那么请求就会压到数据库上，这就是缓存击穿
• 解决方案：由于redis是单进程单实例的，那么redis中请求必然是串行的，所以可以采取如下方案：当第一个请求发现redis中没有需要获取的key时，会通过setnx创建一把锁，并拿到该锁去数据库中获取key，并将key保存到redis。在第一个请求拿到锁的这段时间，其他请求由于没有拿到锁，必然会阻塞，这时可以让他们sleep一段时间，然后重新去redis中查找该key，如果没有查到，继续获取setnx这把锁，如果没获取到锁继续sleep，重复这个过程，直到获取到key，简要步骤如下：

1、get key
2、setnx
	2.1、返回true：去数据库查找key，并将key保存到redis
	2.2、返回false：sleep一段时间，重复一二步骤

• 存在的问题：如果第一个请求线程挂了，那么这个锁何时释放？如果设置锁超时时间，太长会导致其他线程阻塞时间过长，太短则会在该线程没挂并且没有完成数据库操作的期间无故释放锁，导致其他请求线程获取到该锁和该线程并发访问数据库。
• 解决方案：多线程解决，一个线程操作数据库，一个线程监控锁和操作数据库线程的状态，如果操作数据库的线程没有完成数据库操作，并且锁即将释放，则刷新锁超时时间。

穿透

• 产生场景：用户请求的数据是缓存以及数据库都不存在的数据，这时就发生了缓存穿透
• 解决方案：布隆过滤器

雪崩

• 产生场景：大量的key同时失效，间接导致大量访问到达数据库
• 解决方案：
  1、时点性无关：随机过期时间。缺点：对于零点时刻必须大量更换key的业务场景不适用，比如贷款系数一天一变
  2、时点性有关：必须造成雪崩，可以参考缓存击穿的解决方案。或者在业务层上做判断，让请求随机sleep一段时间，即零点延时，不要将流量放到数据库访问层。

redis实现分布式锁

• setnx：setnx作为分布式锁，存在的问题：有可能拿到锁的线程挂了，导致资源浪费
• 锁的超时时间：太长会浪费资源，太短则不能保证拿到锁的线程完成数据库操作
• 多线程(守护线程)：创建监控线程，短间隔时间去监控锁以及操作数据库线程的状态，延长过期时间