Redis[4] 案例介绍+缓存击穿、缓存雪崩、缓存穿透

redis4 案例介绍+缓存击穿、缓存雪崩、缓存穿透

本文整理自小d课堂笔记和java进阶仓库，如有雷同，大部分是人家写的

java进阶仓库：https://doocs.github.io/advanced-java/#/

分布式缓存必考题之缓存击穿+解决方案

• 缓存击穿 (某个热点key缓存失效了)

  • 缓存中没有但数据库中有的数据，假如是热点数据，那key在缓存过期的一刻，同时有大量的请求，这些请求都会击穿到DB，造成瞬时DB请求量大、压力增大。
  • 和缓存雪崩的区别在于这里针对某一key缓存，后者则是很多key。

• 预防

  • **若缓存的数据是基本不会发生更新的：**可以设置热点数据不过期
  • **若缓存的数据更新不频繁：**设置互斥锁

  多个请求到达服务器时，某个请求发现缓存过期了，于是加个锁，然后去数据库请求数据然后更新到缓存中，接下来的其他请求就去缓存中查找

  • 若缓存的数据更新频繁或者在缓存刷新的流程耗时较长的情况下 ： 定时任务定时更新缓存，保证请求能一直访问到对应的缓存

• SpringCache解决方案

  • 缓存的同步 sync
  • sync 可以指示底层将缓存锁住，使只有一个线程可以进入计算，而其他线程堵塞，直到返回结果更新到缓存中

分布式缓存必考题之缓存雪崩+解决方案

• 缓存雪崩 (多个热点key都过期)

  • 大量的key设置了相同的过期时间，导致在缓存在同一时刻全部失效，造成瞬时DB请求量大、压力骤增，引起雪崩

  • 预防

    • 存数据的过期时间设置随机，防止同一时间大量数据过期现象发生
    • 设置热点数据永远不过期，定时任务定时更新

  • SpringCache解决方案

    • 设置差别的过时时间
    • 比如CacheManager配置多个过期时间维度
    • 配置文件 time-to-live 配置

     			time-to-live: 3600000
    # 是否缓存空结果，防止缓存穿透，默以为true
          cache-null-values: true
    

缓存雪崩的事前事中事后的解决方案如下：

• 事前：Redis 高可用，主从+哨兵，Redis cluster，避免全盘崩溃。
• 事中：本地 ehcache 缓存 + hystrix 限流&降级，避免 MySQL 被打死。
• 事后：Redis 持久化，一旦重启，自动从磁盘上加载数据，快速恢复缓存数据。

限流组件，可以设置每秒的请求，有多少能通过组件，剩余的未通过的请求，怎么办？走降级！可以返回一些默认的值，或者友情提示，或者空值。

好处：

• 数据库绝对不会死，限流组件确保了每秒只有多少个请求能通过。
• 只要数据库不死，就是说，对用户来说，2/5 的请求都是可以被处理的。
• 只要有 2/5 的请求可以被处理，就意味着你的系统没死，对用户来说，可能就是点击几次刷不出来页面，但是多点几次，就可以刷出来了

分布式缓存必考题之缓存穿透+解决方案

• 缓存穿透（查询不存在数据）
  • 查询一个不存在的数据，由于缓存是不命中的，并且出于容错考虑，如发起为id为“-1”不存在的数据
  • 如果从存储层查不到数据则不写入缓存这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。存在大量查询不存在的数据，可能DB就挂掉了，这也是黑客利用不存在的key频繁攻击应用的一种方式。
  • 预防
    • 接口层增加校验，数据合理性校验
    • 缓存取不到的数据，在数据库中也没有取到，这时也可以将key-value对写为key-null，设置短点的过期时间，防止同个key被一直攻击
  • SpringCache解决方案
    • 空结果也缓存，默认不配置condition或者unless就行

常用的方法

在缓存之前增加布隆过滤器，将数据库中所有可能的数据哈希映射到布隆过滤器中。然后对每个请求进行如下判断：

• 请求数据的 key 不存在于布隆过滤器中，可以确定数据就一定不会存在于数据库中，系统可以立即返回不存在。
• 请求数据的 key 存在于布隆过滤器中，则继续再向缓存中查询。

使用布隆过滤器能够对访问的请求起到了一定的初筛作用，避免了因数据不存在引起的查询压力。

在线教育-天热销视频榜单实战-List数据结构设计

• 需求
  • 需要一个视频学习榜单，每天更新一次
  • 需要支持人工运营替换榜单位置
• 企业中流程
  • 定时任务计算昨天最多人学习的视频
  • 晚上12点到1点更新到榜单上
  • 预留一个接口，支持人工运营
• 类似场景
  • 京东：热销手机榜单、电脑榜单等
  • 百度：搜索热榜
• 真正高并发下项目，都是预先计算好结果，然后直接存储到缓存中，需要的话直接返回，且存储结构最简单

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-E21I85Ii-1636980700068)(/Users/dk/Library/Application Support/typora-user-images/image-20211108134042136.png)]

自营电商平台-购物车实现案例-Hash数据结构最佳实践

• 背景

  • 电商购物车实现，支持买多件商品，每个商品可以买不同数量
  • 支持高性能处理

• 购物车常见实现方式

  • 实现方式一:存储到数据库
    • 性能存在瓶颈
  • 实现方式二:前端本地存储-localstorage-sessionstorage
    • localstorage在浏览器中存储 key/value 对，没有过期时间。
    • sessionstorage在浏览器中存储 key/value 对,在关闭会话窗口后将会删除这些数据。
  • 实现方式三:后端存储到缓存如redis
    • 可以开启AOF持久化防止重启丢失(推荐)

• 购物车数据结构介绍

  • 一个购物车里面，存在多个购物项
  • 所以 购物车结构是一个双层Map：
    • Map<String,Map<String,String>>
    • 第一层Map，Key是用户id
    • 第二层Map，Key是购物车中商品id，值是购物车数据

• 对应redis里面的存储

  • redis里面有多种数据结构，应该使用哪种？
  • 答案是 hash结构

案例实战需求之大数据下的用户画像标签去重

• 介绍
  • 用户画像 英文为User Profile，是根据用户基本属性、社会属性、行为属性、心理属性等真实信息而抽象出的一个标签化的、虚拟的用户模型。“用户画像”的实质是对 “人”的数字化。
  • 应用场景有很多，比如个性化推荐、精准营销、金融风控、精细化运营等等， 举个例子来理解用户画像的实际应用价值，我们经常用手机网购，淘宝里面的千人千面
  • 通过“标签 tag”来对用户的多维度特征进行提炼和标识，那每个人的用户画像就需要存储，set集合就适合去重
  • 用户画像不止针对某个人，也可以某一人群或行业的画像
  • 利用redis可以很好的去重

案例实战之SortedSet用户积分实时榜单最佳实践

• 背景
  • 用户玩游戏-积分实时榜单
  • IT视频热销实时榜单
  • 电商商品热销实时榜单
  • 一般的排行榜读多写少，可以对 master 进行写入操作，然后多个 slave 进行读取操作。
  • 如果是对象记得重写HashCode与Equals方法

---