Redis的穿透、击穿、雪崩
缓存穿透
在日常开发中，对redis的常见的一种使用方式，如下图所示。在用户访问数据的时候，会先查询redis中是否存在对应数据的缓存，当缓存不存在的时候，就直接查询关系型数据库如mysql。查询到了对应的数据再保存到redis里。因此如果有大量请求，查询在缓存中不存在的数据，就会将大量的请求发送到数据库，可能会把数据库直接打挂。
应对缓存穿透常见的解决方案：
- 每次从数据库从取数的时候，如果数据库中也没有该数据，也将该空值保存在缓存中，并设定一个较短的过期时间。
- 根据业务字段属性提前进行限制，比如根据id查询数据时，先验证id必须>0，根据身份证查询时，先验证身份证符合身份证规范。
- 使用布隆过滤器提前对数据进行限制。
- 设置接口访问频率，同一个用户、IP、设备号限制访问频率，防止少量的用户发出大量请求进行攻击。
缓存击穿
缓存击穿和缓存穿透很相似。缓存击穿一般是指某个热点KEY失效，比如APP首页的BANNER或者活动页面的榜单数据等。因为这些数据的访问并发非常高，当一个热点KEY失效的瞬间，并发的请求查询到数据的缓存，请求会直接进去到数据库，瞬间的高并发会对数据库产生巨大压力，很容易就把数据库打挂。
应对缓存击穿的常见解决方案：
- 防止热点数据失效，将热点数据的缓存设置为不失效的状态。每次更新数据的时候，更新数据库的同时同步跟更新缓存。
- 针对大量相似数据，不好判断哪个数据是热点。比如商品数据，有的商品访问频率特别高，有的商品频率比较低。但是开发阶段不好判断到底哪个商品是热点，则每次访问商品缓存时，延长商品的过期时间，每次更新商品的时候再将数据更新到缓存里，或通过异步任务，异步的将数据库的数据，刷到缓存中。
- 设置锁等待，如果有线程正在查询数据库，就等待该数据写入缓存之后再读取。
缓存雪崩
缓存雪崩的场景，是指redis的key在一个时间里大面积失效，比如通过定时任务将一批数据同步到缓存中，此时这一批数据的过期时间非常相近，缓存同时失效会导致请求都直接请求数据库，将数据库打挂。
应对缓存雪崩的常见解决方案：
1、对缓存数据随机添加过期时间，比如原来都是9:00失效的数据，每个KEY随机加上几秒，使得数据失效时间岔开来。
2、构建多级缓存，比如redis缓存、本地缓存，使得不同的缓存有差异化。
