16 Redis学习 | 青训营笔记

47 阅读2分钟

这是我参与「第五届青训营 」伴学笔记创作活动的第 16 天

为什么需要Redis

  • 数据从单表,演进出了分库分表,不同库表间的传输有瓶颈,出现了缓存需求

  • MySQL从单机演进出了集群

    • 数据量增长
    • 读写数据压力的不断增加
  • 数据分冷热

    • 热数据:经常被访问到的数据
  • 将热数据存储到内存中

Redis应用案例

  • 连续签到:每日签到

    • 使用sds数据结构,可以存储字符串、数字、二进制数据
    • 通常和expire配合使用
    • 场景:存储技术、Session
  • 消息通知:当文章更新时,将更新后的文章推送到ES,用户就能搜索到最新的文章数据

    • 用list作为消息队列——quicklist
    • quicklist由一个双向链表和listpack实现
  • 计数:一个用户有多项计数需求,可以用hash

    • hash数据结构dict
    • rehash:rehash操作是将ht[0]中的数据,全部迁移到ht[1]中。数据量小的场景下,直接将数据从ht[0]拷贝到ht[1]速度是较快的。但是数据量较大时,迁移过程将会明显阻塞用户请求。
    • 渐进式rehash:为避免出现这种情况,使用了rehash方案。基本原理就是,每次用户访问时都会迁移少量数据。将整个迁移过程,平摊到所有的访问用户请求过程中。
  • 排行榜:积分变化时,排名要实时变更

    • 结合dict后,可实现通过key操作跳表的功能

      • XINCRBY myzset 2 “Alex”
      • ZSCORE myzset “Alex”
    • zset数据结构zskiplist

  • 限流:要求1秒内放行的请求为N,超过N则禁止访问

  • 分布式锁:并发场景,要求一次智能有一个协程执行,执行完成后,其他等待中的协程才能执行

    • 可以使用redis的setnx实现,利用了两个特性

      • redis是单线程执行命令
      • setnx只有未设置过才能执行成功

Redis注意事项

  • 大Key:Value大于10KB就是大Key,使用大Key将导致Redis系统不稳定
  • 热Key:一个Key的QPS特别高,将导致Redis实例出现负载突增,负责均衡流量不均的情况。导致单实例故障
  • 慢查询:大Key、热Kye的读写;一次操作过多的Key(mset/hmset/sadd/zadd)
  • 导致缓存穿透、缓存雪崩的场景及避免方案