Redis缓存穿透缓存击穿思维导图

---

前言

记录跟着做视频做项目，商品缓存处理的思维导图

---

思维导图

---

Redis

实战篇

短信验证码的登录注册功能

• 搭建项目
• 基于session的短信登录
• 集群下的session共享问题
• Redis实现共享session
• Redis实现session的刷新问题

商家查询缓存的功能

• 认识缓存

  • 什么是缓存

    • 一种具有高效读写能力的数据暂存区域

  • 缓存的作用

    • 降低后端负载
    • 提高服务读写响应速度

  • 缓存的成本

    • 开发成本
    • 运维成本
    • 一致性问题

• 添加Reis缓存

• 缓存更新策略

  • 三种策略

    • 内存淘汰

      • Redis自带的内存淘汰机制

    • 过期淘汰

      • 利用expire命令设置过期时间

    • 主动更新

      • 主动完成数据库与缓存的同时更新

  • 策略选择

    • 低一致性要求

      • 内存淘汰和过期淘汰

    • 高一致性要求

      • 主动更新
      • 过期淘汰兜底

  • 主动更新的方案

    • Cache Aside

      • 缓存调用者在更新数据库的同时完成对缓存的更新

        • 一致性良好
        • 实现难度一般

    • Read/Write Through

      • 缓存与数据库集成为一个服务，服务保证两者的一致性，对外暴露API接口。调用者调用API，无需知道自己操作的是数据库还是缓存，不关心一致性。

        • 一致性优秀
        • 实现复杂
        • 性能一般

    • Write Back

      • 缓存调用者的CRUD都针对缓存完成。由独立线程异步的将缓存数据写到数据库，实现最终一致

        • 一致性差
        • 性能好
        • 实现复杂

  • Cache Aside的模式选择

    • 更新缓存还是删除缓存？

      • 更新缓存会产生无效更新，并且存在较大的线程安全问题
      • 删除缓存的本质是延迟更新，没有无效更新，线程安全问题相对较低

    • 先操作数据库还是缓存？

      • 先更新数据，再删除缓存

        • 在满足原子性的情况下，安全问题概率较低

      • 先删除缓存，再更新数据

        • 安全问题概率较高

    • 如何确保数据库与缓存操作的原子性

      • 单体系统

        • 利用事务机制

      • 分布式系统

        • 利用分布式事务机制

  • 最佳方案

    • 查询数据时

      • 1、先查询缓存
      • 2、如果命中，直接返回
      • 3、如果缓存未命中，则查询数据库
      • 4、将数据库数据写入缓存
      • 5、返回结果

    • 修改数据库时

      • 1、先修改数据
      • 2、然后删除缓存
      • 确保两者的原子性

• 缓存穿透

  • 产生原因

  • 解决方案

    • 缓存空对象

      • 思路

        • 不存在的数据Redis也在建立缓存，值为空，并设置一个较短的TTL时间

      • 优点

        • 实现简单，维护方便

      • 缺点

        • 额外的内存消耗
        • 短期的数据不一致问题

    • 布隆过滤

      • 思路

        • 利用布隆过滤算法，在请求进入Redis之前先判断是否是否存在

      • 优点

        • 内存占用少

      • 缺点

        • 实现复杂
        • 存在误判的可能性

    • 其他

      • 做好数据的基础格式校验
      • 加强用户权限校验
      • 做好热点参数的限流

• 缓存雪崩

  • 产生原因

    • 在同一时间大量的缓存key同时失效或者Redis服务器宕机，导致大量的请求到达数据库，带来巨大的压力

  • 解决方案

    • 给不同的key添加随机值
    • 利用Redis集群提高服务的可用性
    • 给缓存业务添加降级限流策略
    • 给业务添加多级缓存

• 缓存击穿(热点key)

  • 产生原因

    • 热点Key

      • 在某一段时间被高并发访问
      • 缓存重建耗时长

    • 热点Key突然过期，因为重建耗时长，在这段时间内大量请求落到数据库，带来巨大冲击

  • 解决方案

    • 互斥锁

      • 思路

        • 在缓存重建过程加锁，确保重建过程只有一个线程执行，其他线程等待

      • 优点

        • 实现简单
        • 没有额外内存消耗
        • 一致性好

      • 缺点

        • 等待导致性能下降
        • 有死锁风险

    • 逻辑过期

      • 思路

        • 热点Key缓存永不过期，而是设置一个逻辑过期时间，查询数据时，通过对逻辑过期时间做出判断，来决定是否需要重建缓存
        • 重建缓存也通过互斥锁保证单线程执行
        • 重建缓存利用独立线程异步执行
        • 其他线程无需等待，直接查询旧的数据即可

      • 优点

        • 线程无需等待，性能较好

      • 缺点

        • 不保证一致性
        • 有额外内存消耗
        • 实现复杂

• 缓存工具封装

  • 这里用了泛型和函数式编程，以应对不同类型的数据

优惠卷

分布式锁

总结

感觉跟着整理一遍思维导图，感觉这几天的学习内容，思路清晰了一些。