缓存三大坑

1、缓存穿透
    表现形式：
    --    1）商品1、商品2在缓存和数据中都有
    --    2）一定要买商品3，缓存和数据库都不存在的数据
    --    3）请求每次会直接请求缓存，然后缓存没有直接访问到数据，然后数据也没有，没办法构建出来这个缓存商品闭环，不停的穿透缓存访问数据库

    解决方案：
    --    1）不存在的数据构建缓存
    --    2）布隆过滤器
    
    
2、缓存击穿
    普通流程：
    --    1）用户向应用发送一个查询请求接口
    --    2）通过缓存查看数据是否存在，不存在就直接到db中查询到数据

    热点数据：
    --    1）假设所有用户都来访问热点数据，缓存不存在或者过期
    --    2）直接请求压力全部倒向了db数据库，热点击穿
    
    应对方法：
    --    1）调整缓存过期策略
        --    初阶：永不过期或者过期时间是整个热点期间
        --    高阶：读写分离架构 + Canal数据异构方案：读取永远都从缓存中读取，缓存和数据库的关联使用canal加上数据异构方案进行增量数据同步

    --    2）热点缓存策略
        --    通过热点日志分析，找到热点数据，然后将热点数据打到一块专门的区域进行数据处理
        
    --    3）互斥锁 - mutex
        --    初阶玩家：到期上锁：当一个请求key已经到了加锁的缓存上，后续的请求就不会再打到这个往后面db走了，直接返回
        --    高阶玩家：在到期时提前上锁，当一个请求key打到缓存上面发现已经是锁定状态，说明在到期之前已经有一个请求到db查询数据了，然后做异步缓存刷新后然后把锁拿掉，后面的请求就可以直接从缓存中拿数据了，
3、缓存雪崩
    表现形式：
    --    1）当几个key在一个过期时间相对集中的时间段集体失效
    --    2）应用系统请求就会直接全部打到db上面，直接把数据库打崩了
    
    应对方法：
    --    1）调整缓存过期策略
        --    初阶：永不过期或者过期时间是整个热点期间
        --    高阶：读写分离架构 + Canal数据异构方案：读取永远都从缓存中读取，缓存和数据库的关联使用canal加上数据异构方案进行增量数据同步
    
    --    2）过期时间赛列 
        --    基础时间 + 动态散列时间（随机去分钟值），这样就不会出现一个集中过期的现象
        
    --    3）多层级类型缓存，在redis后面再加一层 redis或者 memcache等等
    
    注意：缓存预热注意过期时间，最好使用时间散列方式