-
概念：一直查询在redis和数据库都没有的数据时，导致数据库的压力过大产生的问题
-
解决方案：
-
对用户进行鉴权、对请求参数进行校验，不合理直接过滤。
-
对查询不到的数据也放到缓存，value为空，设置一定的过期时间。（不太常用，因为如果是随机key就不起作用，且占缓存）
-
使用布隆过滤器，快速判断key是否在数据库中存在，不存在直接返回。（最有效）
-
-
推荐：
- 推荐使用第一种和第三种结合的解决方式
-
解决方案分析
- 第1种是最常用的策略，第2种不太常用，因为如果是随机key就不起作用，且占缓存，第三种最简单有效。实际使用中，可以1、3相结合。
-
概念：高并发的情况下，某一热点key过期，这时候就会导致大量的请求打到数据库，导致数据库的压力过大
-
解决方案：
-
设置热点数据永远不过期。
-
热点数据快过期时，通过另一个异步线程重新设置key。
-
当从缓存数据过期，重新从数据库加载数据到缓存的过程上互斥锁。
-
-
推荐：
- 推荐使用第三种解决方式
-
解决方案分析：
- 第1种的话，数据量大时，缓存量会比较大，第2种，很好理解，但是需要另外的逻辑去维护，会增加系统的复杂度。第3种，是比较常用的方式。
-
概念：高并发的情况下，key同时过期(缓存挂了，或者redisKey的过期时间相同)，这就会导致请求打到数据库中，导致数据库的压力过大
-
解决方案：
-
缓存的失效时间设置为随机值，避免同时失效。
-
redis搭建高可用，主从+哨兵，redis cluster。
-
服务限流、降级，避免数据库被瞬间压崩。
-
-
推荐：
- 推荐使用第二种和第三种结合的方式
-
解决方案分析：
- 第1种只能防止因缓存同时过期导致的缓存失效，第2种可以有效避免单台缓存挂掉的情况。第3种是通过提高服务的高可用，来避免缓存失效带来的影响，是辅助措施。
缓存击穿是一个热点key失效，缓存雪崩是大量的key失效，结果都是导致数据库访问压力过大而崩溃
